自分専用のAI基盤「Personal AI Platform」を作っています。
最近は、ChatGPTから指示を受けるだけではなく、サーバー上にいるCodex自身がタスクを理解し、必要な作業を分解して、実行方法まで考える仕組みを作っています。
その中で、かなり分かりやすい失敗がありました。
AIが600秒、つまり10分間考え続けて、そのままタイムアウトしました。
一度なら「たまたま重かったのかな」と思うところです。
ところが、構造を直してもう一度試したら、また600秒。
2回合わせて20分です。
最終的には、同じ系統の処理をRoot全体で57.371秒まで戻すことができました。
面白かったのは、モデルを軽くしたわけでも、考える時間をさらに増やしたわけでもないことです。
むしろ逆でした。
AIに何を考えさせるかを減らし、何を見せるかを整理し、その瞬間に必要のない道具を使えなくした。
今回効いたのは、AIそのものの性能よりも「仕事の渡し方」でした。
そもそも何を10分も考えていたのか
今回作っていたのは、Root AIが仕事を受け取ったときに、
「この仕事は、どういう手順で進めればいいか」
を自分で決める部分です。
私のシステムでは、これをDynamic Task Graphとして扱っています。
たとえば、ある依頼について、
- これはそのまま実行できる
- 先に調査が必要
- 複数の作業に分解する
- 途中の結果を見て計画を変更する
といった判断を、Root役のAIが行います。
さらに今回の処理では、
外部Webの情報が必要かどうか
まで同時に判断させていました。
つまり一度のAI呼び出しで、
「どういうTask Graphにするか」
と、
「その各タスクにはどのWeb Evidenceが必要か」
をまとめて構造化出力させていたわけです。
これが600秒でタイムアウトしました。
まず「一度に考えさせる」のをやめた
最初に疑ったのは、単純に仕事を詰め込みすぎていることでした。
そこで処理を二つに分けました。
第1段階では、Task Graphの構造だけを作る。
第2段階では、確定したTask Graphを見ながら、必要なWeb Evidenceだけを判断する。
つまり、
計画を作る仕事
と
計画に必要な証拠を決める仕事
を分離しました。
これ自体はかなり自然な設計です。
人間でも、「まず旅行の日程を決めてください」と「各場所について最新の営業時間を確認してください」を一度に考えるより、日程を決めてから営業時間を調べた方が整理しやすい。
実装上も、巨大だった構造化出力を二つの小さなschemaへ分割しました。
これで直るだろう。
そう思いました。
そして、また600秒経った
ところが、実際の環境で試すと、第1段階のTask Graph生成だけで再び600秒に到達しました。
ここが今回、一番面白かったところです。
問題は単純な「一度に要求する出力が多すぎる」ではなかった。
そこで、同じCodex App Serverを使って条件を変えながら切り分けました。
単純なローカル処理なら約23秒。
Knowledge MCPから文書を1つ読む処理も約31秒。
System Truthの詳細なrequirement bindingを外した最小構成のRootなら、Task Graph関連のphaseは約17秒で完了し、Childまで含めても約43秒で成功しました。
モデルそのものが遅いわけではありません。
差分を追っていくと、かなり怪しいものが見えてきました。
System Truthです。
正しい情報を渡しすぎていた
Personal AI Platformでは、AIが古い設計や別のChatの思い込みを使って勝手に開発を進めないように、System Truthという仕組みを持っています。
現在のシステム構成、承認済みの設計、権限境界、実行状態などについて、
「今、このシステムで正しい状態はこれです」
と固定するためのものです。
これは必要です。
むしろ、この仕組みを外して速くしても意味がありません。
ところが今回、Root AIに対して、System Truthに含まれる24個のrequirementについて、文書パスとSHA-256を一つずつ見せていました。
しかも、それらの情報が直近のevent payloadにも含まれ、別の形でも再び文脈へ入っていました。
正確ではあります。
でも、Task Graphを考えるAIが、
「この24個のファイルのSHA-256はそれぞれ何か」
まで知る必要はありません。
必要なのは、
System Truthが正常に検証され、このタスクに正しくbindされている
という事実です。
ここで設計を変えました。
System Truthは削らない。ただし、AIには全部見せない
重要なのは、24個のrequirement自体を消したわけではないことです。
Control Plane側には、これまで通り正確なパスとSHA-256を保持します。
AI側には、
- System Truthのpreflightは完了している
- routeにも正しくbindされている
- requirementは24個ある
- requirement全体のcanonical digestはこれ
- 正確なbindingはControl Planeが保持している
- AIがrequirementを勝手にbindし直してはいけない
という情報だけを渡します。
つまり、
安全性のために機械が知っておく必要がある情報
と、
推論のためにAIが知っておく必要がある情報
を分離しました。
これはかなり重要な違いでした。
AIに長期記憶やKnowledgeを持たせようとすると、つい「知っている情報は全部渡した方が賢くなる」と考えたくなります。
でも実際には、正しい情報であっても、現在の判断に不要ならノイズになります。
情報量だけではありません。
「この情報について何か考える必要があるのか？」
という選択肢そのものを増やしてしまいます。
使わない道具も一時的に閉じた
もう一つ変更したのが、Rootのstructured turn中のtool accessです。
今回のTask Graph生成時点では、すでに必要なSystem Truth packetは準備されています。
それなのにKnowledge MCPへアクセスできる状態にしておくと、AIから見ると、
「追加でKnowledgeを読みに行く」
という行動も選択肢になります。
必要ありません。
そこでTask Graph生成とWeb Evidence判断の二つのstructured phaseでは、Knowledge MCPをturn単位で無効化しました。
モデルはSolのまま。
reasoning effortもhighのままです。
弱いモデルに落として速くしたわけではありません。
強いモデルに、
「ここではこれだけ考えてください」
という狭い仕事場を用意した形です。
同時に、どのphaseでtimeoutしたのかも分かるようにしました。
単なる「turn_timeout」ではなく、
Task Graph生成で止まったのか、
Web Evidence判断で止まったのか、
さらにreasoning中なのかtool利用中なのか、
切り分けられるようにしています。
タイムアウト後に同じ壊れかけのsessionを再利用しないよう、対象turnをinterruptしてApp Server processも捨てるようにしました。
「もう一回やってみる」も、前回の残骸を引き継がないようにしています。
600秒から57.371秒へ
修正後、実際のBrowserから新しいRootを起動して検証しました。
結果は、
Task Graph生成が13.027秒。
Web Evidence判断が5.555秒。
二つのstructured phaseを合わせて18.582秒。
その後のChild処理まで含めたRoot全体が、57.371秒で正常終了しました。
timeoutは0件。
Web Evidenceも実際に取得され、Childの処理も成功しました。
600秒の上限を2回使い切っていた処理が、最終的には1分以内に収まりました。
もちろん、「常に10倍速くなった」という話ではありません。
条件も処理内容も完全に同じではないので、単純なベンチマークとして比較する数字ではないです。
ただ少なくとも今回の障害は、
AIがもっと長く考える必要があったから600秒かかった
わけではありませんでした。
設計がAIを迷わせていました。
AIが遅いとき、「もっと待つ」は意外と危ない
LLMを使っていると、処理が終わらないときに、
「難しい問題だから時間が必要なのだろう」
と考えがちです。
私も最初はそうでした。
だからtimeoutを伸ばす。
モデルを強くする。
reasoning effortを上げる。
コンテキストを増やす。
しかし今回は、すでにSol/highです。
600秒考えさせても終わらないものが、情報と仕事の境界を整理すると57秒で終わりました。
こうなると、問題は計算資源だけではありません。
AIが何を考えるべきなのかを、システム側が十分に限定できているか。
こちらの方が重要です。
AIには「全部できる環境」より、「今これだけやればいい環境」を渡す
今回の経験で、自分の中ではAIシステムの設計方針がかなり明確になりました。
高性能なAIには、たくさんの情報とたくさんのtoolを渡せばよいわけではありません。
KnowledgeもWebもコード実行もサーバー操作もできる。
それ自体は便利です。
でも、一つの判断をするときに全部必要なわけではない。
今回なら、
Task Graphを考えている瞬間に必要なのはTask Graphを考えるための情報だけ。
Web Evidenceを判断するときには、その確定したTask GraphとEvidence判断に必要な情報だけ。
System Truthの完全な検証情報はControl Planeが保持し、AIには「検証済み」という必要十分な表現だけを見せる。
その方が速いだけでなく、責任範囲も明確になります。
AIエージェントを作っていると、どうしても「何でもできるAI」を目指したくなります。
でも実用システムとして必要なのは、むしろ逆なのかもしれません。
何でもできるAIに、その瞬間は何をさせないか。
今回600秒を2回眺めながら直していたのは、結局そこだった気がします。
コメント