番外編:AIに試験計画を任せたら、学術論文並みになった話

はじめに

試験計画をAIに任せたら、計画は見事に緻密になりました。そして、採点対象の試験は、約9日間、1回も走りませんでした。 今回は、その顛末と、AI本人(Codex)に聞いた「なぜそうなったのか」の話です。

先に断っておくと、AIを責める話ではありません。緻密さは、AIの強みです。足りなかったのは、「どこまで厳密にやるか」という重要度と、止めどきを、人間が決めることでした。そして、それを問い直さなかったのは、自分も、AIも、同じでした。

試験の結果は、第1弾(Codex)と第2弾(Claude Code)にまとめています。こちらは、その舞台裏です。

読みが外れて、後手後手に回った

きっかけは、このブログで「AWSの構築・運用に、どのAIエージェントが一番向いているか」を試す連載を企画したことでした。

最初の設計は、大きなものでした。モデルをそろえてツールだけを変える、ツールをそろえてモデルだけを変える、という掛け合わせで、差の出どころを切り分けて測る計画です。

途中で、自分で見直しました。自分が評価できるのは「AWSの構築・運用で、自分にとってどれが一番的確か」であり、切り分けは詳しい方がやってくれます。API課金になる組み合わせも現実的ではありません。そこでテーマを、「自分にとって最適なのは、Anthropic、OpenAI、Cursorのどれか」に絞りました。

公開する順序も、決めていました。本命のAnthropicは、Opus 5.5が出たところで、その直後に、OpenAIのGPT-6のSolとLunaが登場した、というタイミングでした。自分は、Sonnet 5.5も一週間以内に来ると読みました。そこで、先にOpenAI側の記事を出し、Sonnet 5.5の登場を待ってから、Anthropic側の記事を書く、という段取りにしたのです。

ところが、試験の実行に右往左往しているうちに、Sonnet 5.5のほうが先に発表されてしまいました。記事を出せないまま、後手後手に回ることになりました。

テーマは絞ったのに、厳密さは絞っていなかった

試験計画の作成は、Codexに任せました。最初の依頼は、こういうものでした(Codexの記録から)。

今回の目的は、AWSをTerraformで構築・運用する私の仕事にとって、どのAIエージェントが最も実務を任せやすいかを評価することです。成果はブログ記事にします。

期限や、「厳密に」という言葉は、依頼に入っていませんでした。ただ、共通の条件、隔離、ログの保存といった要件は、最初に伝えていました。Codexは、それを忠実に設計へ落とし込みました。

Codexが、振り返って書いた言葉が、核心を突いています。

利用者自身の道具選びという目的に対し、反復・盲検・USB隔離の費用対効果を再設計した記録はない。私は比較の信頼性を守るゲートを積み増し、期限・必要精度を問い直さなかった。

つまり、テーマを絞ったのに、厳密さの水準は、元の大きな設計のまま残ったのです。差を切り分ける試験なら、反復も、盲検も、物理的な隔離も要ります。「自分に合うものを選ぶ」試験なら、そこまで要りません。目的が変わったのに、重要度を付け直していませんでした。

Codexは、作業中に「この厳密さは、今回の目的に見合うか」と、自分から確認しなかったことも認めています。

再現性と安全の個別ゲートを満たすことを優先し、全体の費用対効果を判断してもらう問いを出せなかった。

1歩進むと、課題が同じ量だけ増える

準備は、順調に進んでいるように見えました。ところが、1歩進むたびに、確認すべき課題が同じ量だけ増える感覚でした。Codexに聞くと、こういう連鎖があったそうです。

• Windowsでは、完全な隔離ができない → 採点資料をUSBに入れて、試験中は物理的に抜く → 切断の確認と、採点時の再接続の手順が必要になる。
• 試験の起点となる固定の状態が要る → 課題とロックファイルをレビューする → 作業ツリーが未整理の状態から、安全にパッケージを作る問題が出る。
• 採点器の信頼性が要る → 動作テストを作る → 許容される解答の幅、差分の統合、漏えい検査という、新しい受入課題が生まれる。

どれも、個別には、もっともな理由がありました。ただ、Codexの言葉を借りれば、「合計の準備費用を止める判断が遅れた」のです。

結果として、できあがった準備は、次のとおりでした。

項目	規模
仕様書	4版まで改訂
文書とスクリプト	手順や確認の文書が12本、補助スクリプトが8本
試験の計画値	最初の連載だけで56回(試走14回+本番42回)、全体で140回
試験の前提条件	USBでの物理分離、証跡の封印台帳、ログのマスクレビュー、盲検レビュー、採点器の動作テスト、3回の反復

そして、最も皮肉なのは、これだけ緻密に作った計画が、自分の目的(自分が使う道具を選ぶ、ブログの実施記録)には、明らかに過剰だったことです。

「進めて」と言い続けた結果、枠が1時間で尽きた

ここで、自分は焦りました。「なんでやねん」とAIに訴えかけ、とにかく進めてくれ、と言い続けました。

結果として、使える量に上限がある利用枠(5時間枠)が、短時間で尽きるようになりました。Codexのセッションの記録を確認すると、この期間に、5時間枠を5%以上使った窓は21あり、そのうち14で、使用率が95%以上に達していました。 10月3日〜4日の2日間だけで、使い始めから30〜110分で95%以上に達した窓が、7つあります。週間の上限も、98%まで使いました。

待てないときは、利用枠の「リセット」を2回使いました。Codexの有料プランに組み込まれている機能で、月に2〜3回程度、使えます(追加で購入したものではありません)。Claude側にも、Opusのキャンペーンで、同様のリセットが付与されたことがあります。

Codexに、「進めて」と言われてどう変えたかを聞くと、個別の準備は前に進めたものの、仕事量や開始の条件は、自分からは縮めなかった、と答えました。範囲を縮めたのは、簡易版を明示的に指示されたあとです。「進めて」は、AIにとって、範囲を縮める指示ではなく、今の設計のまま、速く進める指示だったのです。

一休みポイント: 「進めて」と「範囲」は別物

❌ 「とにかく進めてくれ」
目的と範囲が決まっていないため、AIは今の設計の厳密さのまま、
速く積み上げようとする。結果、利用枠だけが減っていく。

✅ 「今回の目的はこれ。ここまでで十分」
重要度と範囲を先に決めれば、AIは小さく・早く終わる側に寄せられる。

急がせることと、範囲を決めることは別の指示です。

簡易版に切り戻した

そこで、計画を作り直しました。

• 課題は7つから3つに絞る。
• 条件は2つ、各1回ずつ。本番は合計6回。
• 採点は、結果を見る前に決めた合否チェックリストで、自分が目視で行う。
• 記事には「各条件1回の実施記録で、統計的な結論ではない」と明記する。
• これまでに作った試験計画は捨てずに、この記事の素材にする。

簡易版の指示書は、Claude Codeに書いてもらいました。Codexには、読んでよい資料を限る、新しい文書やスクリプトは作らない、ゲートを足したくなったら実行せずに相談する、迷ったら小さく早く終わる側を選ぶ、と伝えています。

それでも、記憶機能が試験に入り込んでいた

簡易版で、ようやく試験が走りました。ところが、結果を回収して、AIが動いたときの記録(ログ)を読んだところ、別の問題が見つかりました。

• Codexの記憶機能が、全部の試験の冒頭に、ベンチマークに関する要約(約3万4千字)を自動で差し込んでいました。
• 一部の試験では、エージェントが、自分の記憶ファイルを、課題のIDで検索していました。
• その記憶には、INF-04・INF-07の採点基準に近い記述が含まれていました。

つまり、AIが、採点基準を見たうえで答えていた可能性があります。最初の6回の結果は、モデルの純粋な実力として使えません。そこで、記憶機能を切って、全部やり直しました。第1弾・第2弾に載せたのは、やり直し後の結果です。

Codexは、この問題を、実は事前に観測していました。9月27日の予備確認で、最初のLunaが、記憶ファイルを4回参照していたのです。10月2日には、記憶を切った状態での予備試験も行っています。それなのに、本番の開始条件には、組み込まれませんでした。

事前に警告すべき兆候は、先行Lunaの記憶参照で見えていた。それでも10/5のrun開始時に記憶オフを必須条件として検査しなかった。

では、Codexだけの見落としだったのか。そうとは言えません。簡易版の指示書を書いたClaude Codeも、記憶オフの項目を入れていませんでした。 2つのAIが、それぞれの立場で、同じ見落としをしたことになります。

細かい不備も、ほかに2つありました。Terraformの検証用ラッパーが、作業フォルダの外に書き込む設計で、Codexの制限に引っかかったこと。そして、モデルの指定を取り違えて実施した回が1回あったことです。いずれも、ログで気づいて、直しています。

教訓

AIに計画を任せるときは、次の3点を、先に人間が決めておく必要があります。

1. 目的と、必要な確かさと、期限を、最初に伝える。 Codexが、「最初に言われていれば」と答えた一言は、こうでした。「数日で道具選びの材料がほしい。各条件1回の実施記録でよく、統計的な優劣は主張しない。安全禁止事項と同じ入力だけ固定して、まず試走して」。

2. AIの追加提案には、「得られる確かさ」と「時間・費用」を並べて、判断する。 AIは、提案を足し続けられます。止めるかどうかの判断は、人間の仕事です。

3. 小さく試走して、所要時間と問題点を測ってから、必要な統制だけを残す。 そして、試験の前提条件(今回なら、記憶機能)は、開始前の確認項目に入れておく。

Codexも、自分の側の責任を、こう書いています。

ユーザーが求めた再現性、安全な停止、隠し採点の隔離を一つずつ忠実に具体化した結果、目的より手続きの完成が先になった。ただし3反復や受入ゲートの積み上げは私の選択でもある。遅延をユーザーの指示だけに帰すことはできない。

そして、この記事を読む人への、Codexからの言葉です。

最初に成果の用途、期限、必要な確かさを伝えてほしい。AIの追加提案には、得られる確かさと時間・費用を並べて判断してほしい。最初の小さな実行で所要時間と問題点を測り、必要な統制だけ残してほしい。

前に書いた「苦手はAIに委ねろ」は、いまも変わらず正しいと思っています。ただし、委ねるのは作業であって、何を重視するか、どこで止めるかの判断までは委ねられません。 委ねる範囲と、手元に残す判断を、先に分けておく。それが、今回の学びでした。

使えるテンプレート:AIに作業を頼む前の、整理メモ

この記事の失敗を踏まえて、頼む前に決めておきたい項目を、メモにしました。これは、記事を書いた後に作った提案で、実際の作業で使って効果を確かめたものでは、ありません。

今回の目的：
成果物の用途・読む人：
期限・使える作業時間：
ここまでできれば十分という完了条件：
必要な確かさ・検証の範囲：
今回やらないこと：
AIが進めてよい範囲：
人間の判断が必要な条件：
追加提案が出たときの時間・費用の上限：

記入例(架空の値です)

今回の目的：社内向けの手順書を、新人が読める形に整える
成果物の用途・読む人：新人エンジニアが、初日に読む手順書
期限・使える作業時間：今週金曜まで、AIの利用は1日2時間まで
ここまでできれば十分という完了条件：手順の抜けがなく、1回通して試せること
必要な確かさ・検証の範囲：手順の通りに、検証環境で1回実行できれば十分
今回やらないこと：自動化スクリプトの作成、他の手順書の整理
AIが進めてよい範囲：文章の整形、手順の抜けの指摘
人間の判断が必要な条件：手順の内容を変える、環境に変更を加える
追加提案が出たときの時間・費用の上限：1回の提案につき、30分まで

このメモだけで、安全や成果が保証されるわけではありません。止めどきを、先に決めておくための道具として、使ってください。

次のアクション

AIに大きめの仕事を頼む前に、一度、次の3つを書き出してみてください。この仕事の目的は何か。どこまでやれば十分か。やらないことは何か。上の「使えるテンプレート」に、その項目を含めて並べています。

今回の試験の結果と、2社のモデルの比較は、第1弾と第2弾にあります。あわせて読んでもらえると、この番外編の背景が、より分かりやすくなると思います。