試験の測定データからグラフと集計を作り、報告書の考察の下書きまで用意する
測定データのCSVを入力に、グラフと統計量を作り、社内様式に沿った試験報告書の下書きと考察の案を用意します。研究員の作業は、表計算でグラフを作って文章を書き起こすことから、出てきた図と下書きを見て結論を決めることに変わります。
- 利用ツール
- ChatGPT/Claude/Gemini/Python
- 対象業界
- IT・SaaS/医療/製造
- 対象部門
- 品質管理/研究開発
- 対象業務
- 書類作成/集計・分析
- 主な課題
- データ分析に時間がかかる/属人化している/書類作成に時間がかかる
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/属人化解消/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 試験を行い、測定機器からCSVが出力される
- 研究員がCSVを表計算ソフトで開く
- 不要な行(機器のヘッダー、測定前の安定待ち)を削る
- 条件ごとにデータを並べ替え、平均、標準偏差を計算する
- グラフを作る(軸の範囲、凡例、単位、目盛りを整える)
- Word の様式を開き、試験の目的、条件、方法を書く
- グラフを貼り付け、結果を文章で書く
- 考察を書く(何が言えるか、次に何を試すか)
- 上長がレビューし、修正する
- 試験を行い、測定機器からCSVが出力される
- 研究員が、CSVと試験の条件(試験項目、試料名、条件の一覧)を所定のフォルダに置く
- 自動CSVを読み込み、試験項目ごとに決められた前処理を行う
- 自動決められた集計(平均、標準偏差、n数)を行う
- 自動決められた形のグラフを作る(軸、単位、凡例は試験項目ごとに固定)
- 自動様式に沿った報告書の下書きを作る(目的、条件、方法、結果)
- 自動データから読み取れる事実を、考察の材料として列挙する
- 人研究員が図と数値を確認する
- 人研究員が考察の結論を書く
- 人上長がレビューする
各工程の詳しい説明を読む
- 試験を行い、測定機器からCSVが出力される
- 研究員がCSVを表計算ソフトで開く
- 不要な行(機器のヘッダー、測定前の安定待ち)を削る
- 条件ごとにデータを並べ替え、平均、標準偏差を計算する
- グラフを作る(軸の範囲、凡例、単位、目盛りを整える)
- Word の様式を開き、試験の目的、条件、方法を書く
- グラフを貼り付け、結果を文章で書く
- 考察を書く(何が言えるか、次に何を試すか)
- 上長がレビューし、修正する
問題は4つあります。
(a)グラフを整える作業が長い。 軸のラベル、単位、凡例、目盛り、系列の色。測定データの中身とは関係のない作業に30分かかります。 しかも、同じ試験項目なら毎回同じ形のグラフです。
(b)集計の方法が人によって違う。 外れ値をどう扱うか、n数が少ないときに標準偏差を出すか、有効数字を何桁にするか。決めていないので、報告書ごとに違います。 後から複数の報告書を比較するときに困ります。
(c)本文の型が定まっていない。 試験の目的から書く人、結果から書く人がいます。条件の記載が詳しい人と省く人がいます。半年後に読み返して、何をやったか分からない報告書が出てきます。
(d)考察が書けずに止まる。 データは出ているのに、何を書けばよいか分からず、報告書が数日放置されることがあります。次の試験に進めない原因になります。
- 試験を行い、測定機器からCSVが出力される
- 研究員が、CSVと試験の条件(試験項目、試料名、条件の一覧)を所定のフォルダに置く
- 【自動】 CSVを読み込み、試験項目ごとに決められた前処理を行う
- 【自動】 決められた集計(平均、標準偏差、n数)を行う
- 【自動】 決められた形のグラフを作る(軸、単位、凡例は試験項目ごとに固定)
- 【自動】 様式に沿った報告書の下書きを作る(目的、条件、方法、結果)
- 【自動】 データから読み取れる事実を、考察の材料として列挙する
- 【人】 研究員が図と数値を確認する
- 【人】 研究員が考察の結論を書く
- 【人】 上長がレビューする
自動化されるのは「整える」「集計する」「図にする」「事実を書き出す」の4つです。結論を書くのは研究員です。
7番目の「考察の材料の列挙」が、(d)の「考察が書けずに止まる」に効きます。 「条件Bで平均値が最も高い」「条件Cのばらつきが他の2倍」といった事実が並んでいれば、そこから何を言うかを考えられます。白紙から考えるより速く進みます。
02今回想定するシステム構成
測定機器 → CSV │ ▼ 研究員が所定のフォルダに置く(CSV + 試験条件の記入シート) │ ▼ Python(社内で実行) │ ├──▶ Files API ── CSVをアップロード(file_id を得る) │ ├──▶ Claude API + コード実行ツール │ ─ container_upload でCSVを渡す │ ─ pandas で前処理・集計 │ ─ matplotlib でグラフを作り PNG として出力 │ ─ 生成されたファイルを Files API から取得 │ ├──▶ Claude API(構造化出力) │ ─ 集計結果から「データから読み取れる事実」を列挙 │ ─ 様式に沿った本文の下書き │ ▼ 報告書の下書き(Word / Markdown)+ グラフ(PNG) │ ▼【人が確認】研究員が図と数値を確認し、考察の結論を書く │ ▼ 上長のレビュー → 共有フォルダへ保存
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 実行環境 | Python | Google Colab、社内のJupyter環境 |
| 処理エンジン | Claude API のコード実行ツール | Python(社内環境でmatplotlibを実行) |
| 生成AI | Claude API(構造化出力) | OpenAI API、Gemini API |
| 保管 | 共有フォルダ | SharePoint、Box |
| 報告書の様式 | Word | Markdown、社内の報告書システム |
コード実行ツールは、サンドボックス化されたコンテナでPythonとBashを実行する機能です。 データの分析、可視化、ファイルの作成と編集、アップロードしたファイルの処理を、APIの会話の中で行えます。コンテナには pandas、numpy、scipy、scikit-learn、statsmodels、matplotlib、seaborn などが用意されています。
重要な制約が1つあります。コンテナから外部への通信はできません。 社内のデータベースに直接つなぐ構成は組めません。データはファイルとしてアップロードする必要があります。これは制約であると同時に、データの持ち出し範囲を明確にする利点でもあります。
コード実行ツールを使わず、社内のPython環境で集計とグラフ作成を行う構成も選べます。 測定データを外部に出さずに済むため、機微なデータを扱う場合はこちらが適しています。その場合、AIには集計結果の数値だけを渡し、本文と考察の材料を作らせます。どちらを選ぶかは、扱うデータの機微さで決めてください。 本記事は前者(コード実行ツールを使う構成)で説明し、後者の差分を第9章に書きます。
03どうやって実装するのか
処理の起点を決める
研究員が所定のフォルダにCSVと試験条件の記入シートを置いたことを起点にします。フォルダの監視、または研究員が実行するスクリプトの起動です。
試験条件の記入シートが必須です。 CSVには測定値しか入っていません。何の試験か、試料は何か、どの条件を振ったかは、研究員が書く必要があります。ここを省くと、AIが試験の中身を推測することになり、この構成が壊れます。
記入シートは最小限にします。
| 項目 | 例 |
|---|---|
| 試験項目コード | TENSILE-01(引張試験) |
| 試料名 | 試作品A、試作品B、標準品 |
| 振った条件 | 温度:23℃/60℃/80℃ |
| 目的 | 高温での強度低下を確認する |
| n数 | 各条件5本 |
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 測定データ | 測定値の時系列または点データ | 測定機器のCSV |
| 試験条件の記入シート | 試験項目、試料名、条件、目的、n数 | 研究員が記入 |
| 試験項目の定義 | 前処理の方法、集計の方法、グラフの形 | 部門で管理する定義ファイル |
| 報告書の様式 | 章立てと各章に書く内容 | 部門の様式 |
| 過去の報告書 | 同じ試験項目の過去の報告書(1〜2件) | 共有フォルダ |
| 過去の測定結果 | 同じ試験項目の過去の代表値 | 試験結果の台帳 |
「試験項目の定義」がこの構成の中核です。 試験項目ごとに、次を定義します。
- CSVのどの列を使うか
- どの行を捨てるか(機器のヘッダー、安定待ちの区間)
- 外れ値をどう扱うか(除外するのか、除外せず注記するのか)
- どの統計量を出すか(平均、標準偏差、最大、最小、n数)
- 有効数字を何桁にするか
- グラフの種類、X軸とY軸、軸の範囲、単位、凡例の位置
この定義を作ることが、(b)の「集計の方法が人によって違う」の解決そのものです。 AIを入れなくても、定義を決めるだけで報告書の比較可能性が上がります。
データの取得方法を決める
CSVのアップロード: Files API でアップロードし、file_id を得ます。コード実行ツールにファイルを渡すには、container_upload という content block を使います。
Files API の上限は、1ファイル500MB、組織あたり1TBです。測定データのCSVがこれを超えることはまずありません。アップロード、ダウンロード、一覧、メタデータ取得、削除の操作自体は無料で、メッセージで使ったファイルの内容が入力トークンとして課金されます。
アップロードしたファイルはワークスペース全体からアクセスできます。 ワークスペースにアクセスできるAPIキーであれば、そのワークスペースにアップロードされた任意のファイルを読めます。部門ごと、あるいは機密度ごとにワークスペースを分ける設計にしてください。
expires_in_seconds をアップロード時に指定すると、1時間から90日の範囲で自動的に期限切れにできます。測定データを長く置かない運用にするなら、この指定を使ってください。
試験項目の定義: 部門で管理するJSONまたはYAMLのファイルです。Claude に渡すのではなく、Pythonが読んでコード実行ツールへの指示に組み込みます。
AIへ渡す前に整形する
- CSVの文字コードと区切りの確認 … 測定機器のCSVは Shift_JIS のことが多く、ヘッダーが数行あります。試験項目の定義に「先頭◯行を飛ばす」を書きます
- 列名の正規化 … 機器のファームウェアが変わると列名が変わることがあります。定義ファイルに列名の対応を書き、一致しなければ処理を止めます
- 試験条件の記入シートの検証 … 必須項目が埋まっているかを確認します。空欄があれば処理を止め、研究員に返します。推測で埋めません
- データ件数の確認 … 記入シートの n数 と、CSVの実際の行数が合うかを確認します。合わない場合は処理を止めます。 測定の失敗や、ファイルの取り違えの可能性があります
- 機微な情報の確認 … CSVに顧客名や未公開の製品名が入っていないかを確認します。入っている場合は、コード(試料A、試料B)に置き換えます
AIに処理させる
処理は2段階に分かれます。間に集計とグラフ作成が入ります。
1段階目:コード実行ツールによる集計とグラフ作成
| 処理 | 内容 |
|---|---|
| 前処理 | 定義に従って行と列を選ぶ |
| 集計 | 条件ごとの平均、標準偏差、最大、最小、n数 |
| 外れ値の判定 | 定義に従って判定する。除外するかどうかは定義に従い、AIが決めない |
| グラフ作成 | 定義に従った形のグラフをPNGで出力する |
| 数値の書き出し | 集計結果をCSVまたはJSONで出力する |
2段階目:本文と考察の材料の作成
| 処理 | 内容 |
|---|---|
| 本文の下書き | 様式に沿って、目的、条件、方法、結果を書く |
| 事実の列挙 | 集計結果から読み取れる事実を箇条書きにする |
| 過去との比較 | 同じ試験項目の過去の代表値と比べ、差がある点を挙げる |
| 確認すべき点の指摘 | n数が少ない、ばらつきが大きい、外れ値があるといった注意点を挙げる |
2段階目には、CSVの生データを渡しません。集計結果だけを渡します。 理由は2つあります。生データを渡すと、AIが独自に集計し直して、グラフと違う数値を書く可能性があります。また、渡すデータが減れば、外部に出る情報が減ります。
指示内容を固定する
1段階目(コード実行ツールへの指示)
添付したCSVを、次の定義に従って処理してください。
【CSVの読み込み】
- エンコーディング: {encoding}
- 先頭 {skip_rows} 行を読み飛ばす
- 使用する列: {columns}
- 列名が定義と一致しない場合は、処理を中止して
一致しなかった列名を報告してください。
【前処理】
{preprocessing_rules}
【集計】
- 条件ごとに、平均 / 標準偏差 / 最大 / 最小 / n数 を算出
- 有効数字: {significant_digits} 桁
- 外れ値の扱い: {outlier_rule}
※ このルール以外の判断で値を除外しないでください。
【グラフ】
{chart_spec}
- ファイル名: chart_1.png
- 日本語ラベルは使わず、英字で出力してください。
【出力】
- 集計結果を summary.csv として保存
- 処理の途中で捨てた行数を dropped_rows.txt に記録
2段階目(本文と考察の材料)
あなたは研究開発部門の報告書作成を支援する担当者です。
集計結果と試験条件から、報告書の下書きを作ってください。
【厳守事項】
- 渡された数値をそのまま使ってください。
計算し直したり、丸め直したりしないでください。
- 考察の結論を書かないでください。
「したがって条件Bを採用すべき」「原因は◯◯と考えられる」
といった判断や推定を書かないでください。
あなたが書くのは、データから読み取れる事実だけです。
- 原因の推測を書かないでください。
「ばらつきが大きいのは測定誤差によるものと思われる」は禁止です。
「条件Cの標準偏差は他の条件の約2倍」とだけ書いてください。
- 試験条件の記入シートに書かれていない条件を補わないでください。
- n数が3以下の条件については、標準偏差の記述に
「n数が少ない」旨を必ず添えてください。
- 最後に「研究員が確認・判断すべき点」を箇条書きで挙げてください。
【試験条件】{test_conditions}
【集計結果】{summary}
【捨てた行数】{dropped_rows}
【報告書の様式】{report_template}
【同じ試験項目の過去の代表値】{past_results}
「考察の結論を書かない」「原因の推測を書かない」の2つが、この構成で最も重要な指示です。
生成AIは、データを見せられると原因を説明しようとします。「高温で強度が下がったのは分子鎖の運動性が高まったため」といった文章を書きます。もっともらしく読めますが、それはこの試験で検証したことではありません。 研究員がそのまま残せば、根拠のない推定が社内の報告書に載ります。半年後、別の研究員がそれを前提に次の試験を組みます。
出力形式を固定する
1段階目の出力: summary.csv(集計結果)、chart_1.png(グラフ)、dropped_rows.txt(捨てた行数)。コード実行ツールが生成したファイルは、応答の bash_code_execution_tool_result の content block に file_id が現れ、Files API からダウンロードできます。アップロードしたファイルはダウンロードできず、コード実行ツールやスキルが生成したファイルだけがダウンロードできます。
2段階目の出力:
{
"report_sections": {
"purpose": "",
"conditions": "",
"method": "",
"results": ""
},
"observed_facts": [],
"comparison_with_past": [],
"points_to_check": [],
"n_warnings": []
}
observed_facts(事実)と、結論を書く欄を分けています。 結論の欄そのものを出力に作らないのが設計上の意図です。研究員がWordの様式に貼り付けたとき、考察の欄は空です。空欄は埋めなければならないので、研究員が必ず書きます。
システムへ連携する
報告書の生成: Python で Word の様式にテキストとPNGを流し込むか、Markdown で出力してから変換します。考察の欄は空欄のまま出力します。
試験結果の台帳: 集計結果を台帳(スプレッドシートまたはデータベース)に追記します。試験項目、試料名、条件、代表値、報告書へのリンク。これが次回の「過去の代表値」の入力になります。
測定機器との直接連携はしません。 研究員がCSVをフォルダに置く運用のままにします。機器はメーカーもファームウェアもばらばらで、直接連携を組むと保守が続きません。
人が確認する
図と数値は全件、研究員が確認します。考察の結論は研究員が書きます。上長のレビューも従来どおり行います。
研究員が必ず確認する点を、points_to_check として出力させます。加えて、運用で次を決めます。
- グラフの軸の範囲が適切か(自動設定で見づらくなっていないか)
- 捨てた行数(
dropped_rows)が想定どおりか。想定より多ければ、前処理の定義かデータに問題がある - n数が記入シートと一致しているか
- 有効数字が定義どおりか
「捨てた行数」の確認を必ず入れてください。 前処理の条件が合わないと、静かに大量の行が捨てられます。グラフは何事もなかったように描かれます。気づけるのは、捨てた行数を見たときだけです。
例外に対処する
| 起きること | 対応 |
|---|---|
| CSVの列名が定義と違う | 処理を止め、一致しなかった列名を報告する。推測で対応づけない |
| 記入シートの必須項目が空欄 | 処理を止め、研究員に返す |
| n数が記入シートと合わない | 処理を止める。測定の失敗かファイルの取り違えの可能性がある |
| 外れ値がある | 定義に従って扱う。定義に無い判断で除外しない。除外した場合は必ず報告書に記載する |
| 捨てた行が想定より多い | 処理は続けるが、points_to_check の先頭に出す |
| グラフの日本語が文字化けする | 英字ラベルで出力する。日本語が必要なら、フォントをコンテナに用意する必要がある |
| AIが原因の推測を書く | プロンプトで禁止する。出力スキーマに結論の欄を作らない |
| AIが数値を丸め直す | 集計結果をそのまま使う指示を出す。出力の数値と summary.csv を照合する |
| コンテナから社内DBにつなごうとする | できない。 外部への通信は許可されていない。必要なデータはファイルとして渡す |
| コンテナが期限切れになる | コンテナは作成から30日で期限切れになる。1件の報告書作成は1回の処理で完結させる設計にする |
| 同じ試験項目で定義が古い | 定義ファイルに版と更新日を持たせ、報告書に記録する |
記録を残す
- 測定データの原本(CSV)
- 試験条件の記入シート
- 使用した試験項目の定義(版を含む)
- 集計結果(
summary.csv) - 捨てた行数
- 生成されたグラフ
- AIが列挙した事実と、研究員が書いた考察
- 報告書の最終版
「使用した定義の版」を必ず残してください。 半年後に定義が変わっていた場合、過去の報告書と現在の報告書を比べてよいかが判断できません。
測定データは自社の技術情報です。保管場所のアクセス権限を部門に限定してください。
04実装レベルの3段階
測定データを外部に出せない場合の構成を書いておきます。 コード実行ツールを使わず、社内のPython環境で pandas と matplotlib による集計とグラフ作成を行います。 AIには集計結果の数値(summary.csv の中身)だけを渡し、本文と事実の列挙をさせます。生データは社内にとどまります。 この構成の差は次のとおりです。 機微なデータを扱う場合は後者を選んでください。 実装の手間は増えますが、一度書けば毎回同じ処理が走ります。むしろ、試験項目の定義が固まっているならコードのほうが確実です。
05工数削減シミュレーション
導入後 60件 × 30分 ÷ 60 = 30 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 月40件以上の試験報告書を作成し、測定データがCSVまたはExcelで機器から取り出せること。試験の条件と評価項目が試験項目ごとに決まっていること。報告書の様式が社内で統一されていること。研究員がグラフの作成に時間を使っている自覚があること。
- 試験が月10件未満で、報告書の形式も都度変わる場合。測定データが紙の記録紙でしか残らない場合(先にデータ化が必要)。外部に提出する試験成績書(認証機関向けなど)を作る用途(記載内容の要件が別にあり、この構成の対象ではない)。
07最小構成で試す方法
- 件数の多い試験項目を1つ選ぶ(月10件以上あるもの)
- その試験項目の定義を書く(前処理、集計、有効数字、外れ値の扱い、グラフの形)
- 過去の報告書5件分のCSVを用意する
- 定義に従って、表計算ソフトで集計しグラフを作る(手作業)
- 過去の報告書と並べ、数値とグラフが一致するかを確認する
2番目がこの構成の本体です。 定義を書く作業は、部門で議論が必要です。「外れ値をどうするか」は、これまで暗黙だったものを明文化することになります。この議論そのものに価値があります。
4番目を手作業でやるのが重要です。 定義が書けているなら手作業でも同じ結果が出るはずです。出ないなら、定義が不完全です。定義が不完全なまま自動化すると、誰も検算できない数値が出てきます。
判断の目安は次のとおりです。
| 結果 | 判断 |
|---|---|
| 定義に従った集計が、過去の報告書と一致する | 進めてよい |
| 一致しない報告書がある | その報告書で何をしたかを確認する。定義に例外を書くか、過去が誤りだったかを判断する |
| 定義が書けない(毎回違う) | この試験項目は自動化に向かない。別の試験項目を選ぶ |
定義が書けたら、コード実行ツールで同じ処理を試します。手作業の結果と一致することを確認してから、本文の生成に進んでください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| AIが原因の推測を書く | プロンプトで禁止する。出力スキーマに考察・結論の欄を作らない |
| AIが数値を丸め直す | 集計結果をそのまま使わせる。出力の数値と summary.csv を照合する |
| 静かに大量の行が捨てられる | 捨てた行数を必ず出力し、確認項目に入れる |
| グラフの日本語が文字化けする | 英字ラベルにする。日本語が必要ならフォントをコンテナに用意する |
| CSVの列名が変わる(機器の更新) | 定義と一致しなければ処理を止める。推測で対応づけない |
| Shift_JIS のCSVが読めない | 定義にエンコーディングを書く |
| コンテナから社内DBにつなげない | 外部通信はできない。データはファイルで渡す設計にする |
| 外れ値の扱いが人によって違う | 定義に書く。定義に無い判断で除外させない |
| 定義が古いまま使われる | 定義に版と更新日を持たせ、報告書に記録する |
| 考察の欄をAIの文章で埋めてしまう | 出力を空欄にする。上長のレビューで「考察が事実の言い換えになっていないか」を見る |
| アップロードしたファイルが他の案件から読める | ワークスペースを部門または機密度で分ける。ファイルIDを外部から受け取らない |
| ファイルが溜まる | アップロード時に expires_in_seconds を指定する(1時間〜90日) |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 試験の測定値、試料の名称、試験条件。自社の技術情報そのものであり、未公開の開発品に関する情報を含みます。
- 外部AIへの入力可否が最大の論点 … 測定データを外部サービスに渡してよいかを、導入前に部門と情報システムで決めてください。 出せない場合は、第9章の「社内で集計する構成」を選びます
- 試料名と製品名 … 「試作品A」「試作品B」のようなコードに置き換えれば、何の製品の試験かは外部から分かりません。置き換えの手間は小さく、効果は大きいので、既定でそうすることを勧めます
- ワークスペースの分離 … Files API にアップロードしたファイルは、ワークスペース全体からアクセスできます。 ワークスペースにアクセスできるAPIキーであれば、そのワークスペースの任意のファイルを読めます。部門ごと、機密度ごとにワークスペースを分けてください
- ファイルIDを外部から受け取らない … 利用者や外部の入力から
file_idを受け取る作りにしないでください。他の案件のファイルを読める状態になります - ファイルの期限 …
expires_in_secondsを指定して自動的に期限切れにできます(1時間〜90日)。ただしこれは確実な削除の手段ではありません。 期限前に消すなら削除APIを使ってください - 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
- 自動実行してよい範囲 … 集計、グラフ作成、本文の下書き、事実の列挙までです。考察の結論と、試験の合否判定は人が行います
- 社外提出用の文書に使わない … 認証機関向けの試験成績書、顧客への品質証明書には使わないでください。記載内容と作成者の要件が別にあります
誤りが起きた場合のリスクは、根拠のない推定が社内の報告書に残ること、誤った集計結果に基づいて開発の方向が決まることです。どちらも、気づくまでに時間がかかる種類の誤りです。
10まず何から始めるか
1〜2週目:試験項目を1つ選び、定義を書く
月10件以上ある試験項目を1つ選びます。前処理、集計、有効数字、外れ値の扱い、グラフの形を文書に書きます。部門で議論してください。 「外れ値をどうするか」は、これまで人によって違っていたはずです。
3週目:手作業で検算する
過去の報告書5件分のCSVについて、定義に従って表計算ソフトで集計とグラフ作成を行います。過去の報告書と一致するかを確認します。一致しないものがあれば、その理由を確かめてから進んでください。
4週目:測定データを外部に出せるかを決める
部門と情報システムで判断します。出せないなら、社内のPython環境で集計する構成に切り替えます。判断が済むまで実装に入らないでください。 構成が変わります。
2か月目:集計とグラフの自動化を作る
CSVを置くと summary.csv とグラフが出るところまでを作ります。手作業の結果と一致することを、5件で確認してください。
3か月目:本文と事実の列挙を足す
本文の下書きと、observed_facts の生成を足します。考察の欄は空欄で出力します。
研究員2名で1か月使い、次を記録します。
- 図と数値を直した件数
- AIが書いた事実の記述のうち、誤っていたもの
- 考察の欄が、事実の言い換えで埋められていないか
3つ目が最も重要です。 考察の欄を空にしても、研究員が observed_facts をそのまま貼り付けて埋めることがあります。それでは考察になりません。上長のレビューで、この点を見る運用にしてください。
4か月目以降: 他の試験項目に広げます。試験項目ごとに定義を書く作業が必要なので、一気に広げず、件数の多いものから順に進めてください。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Claude API のコード実行ツールが、サンドボックス化されたコンテナでPythonとBashを実行し、データ分析・可視化・ファイルの作成と編集・アップロードしたファイルの処理を行えること。コンテナには pandas、numpy、scipy、scikit-learn、statsmodels、matplotlib、seaborn が用意されていること。コンテナの仕様は メモリ5GiB、ディスク5GiB、CPU 1、外部への通信は許可されないこと。コンテナは作成から30日で期限切れになること。組織あたり月1,550時間まで無料で、超過分はコンテナあたり1時間0.05米ドルであること。生成されたファイルの file_id は bash_code_execution_tool_result の content block に現れること | Claude Docs: Code execution tool | 2026-09-15 |
Files API でファイルをアップロードして file_id を得て、Messages リクエストから参照できること。コード実行ツールへは container_upload の content block で渡すこと。上限は1ファイル500MB、組織あたり1TB。アップロードしたファイルはワークスペース全体からアクセスでき、ワークスペースにアクセスできるAPIキーであれば任意のファイルを読めること。expires_in_seconds(3,600秒〜7,776,000秒=1時間〜90日)で期限を指定できること。ファイル操作自体は無料で、メッセージで使った内容が入力トークンとして課金されること。アップロードしたファイルはダウンロードできず、スキルやコード実行ツールが生成したファイルのみダウンロードできること | Claude Docs: Files API | 2026-09-15 |
Claude API の構造化出力が、JSON Schema で指定した形式に沿った応答を保証すること。定義していないフィールドは返らない(additionalProperties は false が必須) | Claude Docs: Structured outputs | 2026-09-15 |
測定機器からのCSVの形式は機器とメーカーによって異なります。この部分は利用環境に応じた個別確認が必要です。 測定データを外部の生成AIサービスへ渡すことの可否は、自社の情報管理規程に照らして判断してください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。認証機関向けの試験成績書や顧客への品質証明書には、この構成を使わないでください。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0073)についてのご相談はこちらから。
