実験レポートは自分で書きたい。図表作成と配置をCodexに任せる仕組みを作った

実験レポートの本文は、自分で考えて書きたい。けれど、図表を作ったり、配置を整えたりする作業は面倒に感じていました。

そこで、図表の作成や組版をCodexに支援してもらい、自分が本文を書くための「骨格」を先に用意するワークフローを作りました。GitHubで公開しているlab-report-frameworkです。

実際に骨格まで作ってみると、すごくよかったです。ただ、一つ気づいたことがあります。「文章1」とだけ書かれた枠では、何を書けばよいのか分からないのです。

この記事では、作った仕組みと、骨格を試して分かったこと、いま修正している部分を紹介します。図表づくりやレポートの体裁に手間を感じている理系大学生に向けた制作記録です。

大学の実験で使ったPDFは公開できないため、掲載するPDF画像はGitHubで公開している架空データのサンプルです。僕自身が実際に使った範囲は、骨格を作るところまでです。

本文を書くことと、図表を整えることを分けたかった

実験レポートには、結果を読み取り、何が分かったかを自分の言葉で説明する作業があります。その一方で、データを表にまとめる、グラフを作る、図表の番号や配置を整える、といった作業も必要です。

僕が面倒に感じていたのは、この図表作成や配置でした。本文を自分で書きたいという気持ちと、周辺の作業を手伝ってほしいという気持ちがありました。

図表を作る処理なら、入力データと処理内容をコードに残せます。条件をそろえて実行し直し、結果を確かめやすいのではないか。そう考えたことが、今回の分担につながっています。

もちろん、コードになれば計算方法やグラフの選び方まで正しくなるわけではありません。元のデータ、使う式、単位や軸の取り方は確認が必要です。狙ったのは、処理内容を見直せる形で残し、図表を作り直しやすくすることでした。

CodexとPython、LaTeXでレポートの骨格を作る

lab-report-frameworkは、手元のPCでCodexと使う、作業手順・テンプレート・検査スクリプトのまとまりです。ブラウザでファイルを選ぶだけのWebアプリではなく、ローカルのフォルダを開いて作業します。

Codexが資料やデータを読みながら必要なファイルを編集し、Pythonで集計や検査を行い、LaTeXでPDFに組みます。リポジトリのPythonスクリプト自体がAIを呼び出し、課題を解釈する構成ではありません。

役割は、次のように分けています。

文章の意味や考察の妥当性まで、Pythonの検査で保証できるわけではありません。自分で読んで、結果と説明が合っているかを確かめる部分は残ります。

実験前の条件をそろえてから、骨格へ進む

ワークフローの最初には、実習書、課題文、採点基準、提出条件を確認する段階を置いています。図表を整える前に、何を求められている課題なのかをそろえるためです。

公開版では、課題ごとに使う知識や手法、まだ持ち込まない後続課題の内容、提出するコードと集計用の補助コードの区別なども記録する設計にしています。

全体の流れは、次のとおりです。

1. 実験前に確認する：課題の条件、AIの利用範囲、実験計画を確認する。
2. 結果と骨格を確認する：実験・分析の結果、図表、見出し、文章を書く枠を確認する。
3. 自分で本文を書き、完成稿を確認する：送った原文の反映、図表との対応、最終PDFを確認する。

リポジトリでは、この大きな確認をG1・G2・G3と呼んでいます。以下は、そのうち僕が試した骨格の段階の話です。

図表と「文章を書く場所」が入った骨格PDF

骨格には、見出し、図表、数式、コード、参考文献と、本文を入れる枠を配置します。先にレポート全体の形を見られるようにしたものです。

下の画像は、公開サンプル「ソートアルゴリズムの実行時間比較」の骨格PDFです。数値は架空データで、実際の処理速度を測った結果ではありません。画像を押すと拡大して確認できます。

次のページにはグラフと、考察・結論の枠があります。本文を埋める前から、どの図表があり、どの順に説明していくかをPDFで見られます。

サンプル全体は、GitHubの骨格PDFから見られます。

僕も骨格まで作ってみて、すごくよかったと感じています。ただ、実際にこの先で文章を書こうとすると、枠の表示には足りないものがありました。

「文章1」だけでは、何を書けばよいのか分からない

骨格に「文章1」「文章2」と枠があっても、その番号だけでは、何を説明する場所なのかが分かりません。

例えば図の近くに枠がある場合でも、図そのものを説明するのか、図から読み取れる傾向を書くのか、理由を考察するのかでは、書く内容が変わります。文章を入れる場所を決めるだけでなく、その場所で何を書くのかも分かる必要があると気づきました。

そこで今は、文章の番号に加えて、書くべき内容の大まかな説明も骨格と一緒に表示するように修正しています。

公開版にも、文章枠ごとの目的や必要な論点を管理し、別の執筆案内へまとめる仕組みはあります。いま改善しているのは、骨格を見ながら書くときに、その内容が分かるようにする表示の部分です。

自分が書く本文の中身は自分で考えながら、「この場所では何を説明するのか」を確認できるようにしたいと思っています。

いま使った範囲と、これから確かめたいこと

現時点で僕が実際に試したのは、骨格を作るところまでです。本文をすべて書いて完成させたときの使い心地や、どれだけ時間を短縮できるかは、これから確かめる部分です。

仕組みとしては、本人が送った文章の原文と組版後の文章を分けて保存し、意味や数値を変える修正には本人の確認を求める手順も用意しています。これは公開版の仕様であり、僕が今回、完成レポートの提出まで使ったという意味ではありません。

今後確認したいのは、次の三つです。

• 文章の役割が見えることで、何を書き始めるか判断しやすくなるか。
• 実際に本文を入れたとき、図表との対応や配置にどんな調整が必要になるか。
• 本文の差し替えやデータの変更後も、意図した内容がPDFへ反映されるか。

まずは「文章1：図1の説明」のような表示に改良し、骨格から執筆へ進みやすくなるか試していきます。

試してみたい人へ：公開サンプルから確認できます

仕組みとサンプルは、GitHubのlab-report-frameworkで公開しています。まずはREADMEと骨格PDFを見ると、どんな形で作業するのかを確認できます。

手元で動かすには、ローカルのファイルやコマンドを扱えるCodex環境、Python 3.10以上、必要なPythonパッケージ、PDF生成用のlatexmk・LuaLaTeXなどを用意します。Codexの利用条件や費用は、利用するプラン・環境で確認してください。

2026年10月12日の掲載準備では、公開リポジトリの取得と、簡易診断によるPython依存・PDF生成コマンドの存在確認を行いました。この確認は、大学の実レポートの再実行や、全機能の動作検証ではありません。

1. READMEと公開サンプルを見る。必要な環境と、作りたいレポートの形式に合うかを確認します。
2. リポジトリを取得し、最上位のフォルダを開く。Codexでは、AGENTS.mdがあるlab-report-framework/直下を作業場所にします。
3. 環境を診断する。最初はCodexに「このリポジトリの説明に沿って必要な環境を確認して」と依頼します。詳しい手順は利用ガイドで確認できます。
4. 授業の条件を確認してから、自分の課題へ進む。AI利用が認められる範囲、指定書式、資料やデータをCodexへ渡してよいかを先に確認します。

この仕組みはローカルでPDFを生成しますが、Codexに渡す資料の扱いは利用方法や設定によります。学校の資料を扱う際は、その利用条件に従ってください。また、標準の書式が授業指定と違う場合は調整が必要です。

課題の条件をそろえて始める際の依頼文は、READMEに次のように用意しています。

この実験を始めたい。実習書と採点基準を全読し、G1確認票を作って。

コードをGitHubに置くまでの流れを知りたい場合は、GitHubにコードを保存する手順も参考にしてください。

別の制作物でも、実際のデータや使い方から改善点が見つかりました。MaskSheetで実務のExcelを読み込み、表の扱いや操作を直した記録では、その過程を紹介しています。

レポートは自分で書きたい。そのための図表や骨格を、使いやすい形で用意したい。今回作った仕組みも、実際に使って気づいた点から少しずつ直していきます。

この制作記録のように、本人のメモから原稿・画像・投稿まで進めるブログ側の環境も使っています。CodexとEasy MCP AIでWordPressを管理する手順では、下書きから公開・更新までの構成と配布テンプレートを紹介しています。

仕様・サンプルの参照先

2026年10月12日に公開リポジトリのv7.2仕様とサンプルを確認しました。本文中の「修正中」の表示は、現在進めている改善として区別しています。

• README：基本方針と使い方
• 現在のシステム仕様：実装と確認できる範囲
• 日常の進め方：執筆案内・本文受領・変更確認