昨年末、私の OneUp 自動投稿パイプラインは深夜二時に同じ投稿を八回送信した。八つのプラットフォーム、それぞれに八件の重複コンテンツ。朝起きてスマホの通知を見たとき、四十分かけて手動で投稿を削除した。

▶ 要約を聴く
AI合成音声・著者本人の声のクローン

その日学んだ教訓はシンプルだ：Agent を作るのは難しくない、難しいのはそれを暴走させないことだ。

この一年で私は三つの Agent システムを構築した。討論エンジンは GPT-4o、Gemini、Grok を互いに討論させ、Perplexity がファクトチェックする。OneUp パイプラインは Google Sheet からスケジュールを読み込み、DALL-E で画像を生成し、八つのプラットフォームへ自動投稿する。私たちの AI プラットフォームの生産ライン監視は深夜三時に自動でパラメータを調整する。どれもが私に異なることを教えてくれた。

これは理論ではない。私が落とし穴を踏みながら帰納した五つの原則だ。

着手する前にまず三つの問いに答えよ

一行のコードも書く前に、私は今、自分に三つの問いへの回答を強制する。この Agent は何の問題を解決するのか？その権限の範囲はどこまでか？それが正しくやったとどうやって知るのか？

基本的に聞こえるかもしれないが、私の討論エンジンの初版はまさに二番目の問いを考え抜いていなかった。モデルに討論のラウンド数を自由に決めさせた結果、あるとき二十七ラウンドも走り、API のクォータを焼き尽くした。後に私は厳格な上限を加えた：最大五ラウンド、超えたら強制的に収束させる。

位置づけの曖昧な Agent とは、制御不能なブラックボックスそのものだ。まず境界を描き、それからコードを書く。

API 優先、ブラウザは最後の手段

Agent の価値はツールを呼び出して多段階のタスクを完遂することにある。だがツール統合の複雑度は指数関数的に増大する。

私が OneUp パイプラインで学んだ最も痛い一課はこうだ：最初はブラウザ自動化で投稿スケジュールを組もうとしたが、UI が改版されるたびにすべて壊れた。後に API へ切り替えると、安定性は 60% から一気に 99% へ跳ね上がった。今の私の原則はシンプルだ——API の安定性は常に優先し、ブラウザ自動化は API が存在しない場合にのみ検討する。

データ処理も同じだ。入力データがクリーンでなければ、Agent はゴミの上で意思決定をする。私は〈AI の嵐から突破する〉で論じたが、構造設計こそが新たな核心的競争力だ——Agent の構造設計は、データクレンジングというその一歩から始まっている。

モジュールに分解せよ、そうすれば誤りを特定できる

大型の Agent は保守が難しい。今、私のすべてのシステムは四つのモジュールに分解されている：Input 処理 → 決策ロジック → ツール呼び出し → 結果の後処理。各モジュールは独立して検証可能であり、ロールバック可能だ。

討論エンジンはまさにこのように設計されている。Input モジュールはテーマとモード（dialogue/duo/adversarial）の解析を担う。決策モジュールはラウンド制御と収束判断を担う。ツール呼び出しモジュールは四つのモデルの API 呼び出しを処理する。後処理モジュールは結果を markdown として保存する。どのモジュールに問題が起きても、他の部分まで巻き添えで壊すことはない。

これは私が記憶に書き留めた協働の原則でもある：複雑なエンジニアリングはまず Phase に分け、各 Phase が独立して検証可能でなければならない。一度に処理した結果は、たいてい途中で詰まり、そして前段でうまくいっていた部分まで一緒に壊してしまう。

一歩ごとにログを残せ

Agent の動作プロセスは透明でなければならない。さもなければ誤りが起きたとき、どこが壊れたのか皆目わからなくなる。

私の OneUp パイプラインの八回重複投稿事件は、まさにログが欠けていたために起きた。API が timeout を返し、スクリプトが八回リトライし、その都度新しい投稿を成功裏にスケジュールしてしまった。もしあのとき API 呼び出しごとの返答ステータスを記録していれば、二回目のリトライ時に、一回目が実はすでに成功していたことに気づけたはずだ。

今、私のすべての Agent は三層の監視を備えている：操作ログ（各ステップで何をしたか）、決策経路（なぜこの選択をしたか）、コスト追跡（どれだけ API クォータを消費したか）。透明性は贅沢品ではない、生存の条件だ。

最小のシーンから始めよ

最後の原則は最もシンプルでありながら、最も見過ごされがちだ：小さく始めること。

私たちの AI プラットフォームの監視システムは、最初から全生産ラインを対象にしていたわけではない。まず一つの生産ラインの一つのパラメータだけを監視させ、二週間走らせてロジックが正しいことを確認してから、段階的に拡張した。私は〈認知で負けているのではない〉で「まずゴミを一つ作ってみろ」と語ったが——Agent も同じだ。まず粗削りな POC を走らせ、稼働の中で最適化するほうが、三ヶ月かけて完璧なシステムを計画してリリースした途端に爆発するよりも、百倍ましだ。

Agent の価値は人を置き換えることにはない。人の能力の境界を拡張することにある。だがその拡張の前提は、まずそれを飼いならすことだ——位置づけを明確にし、モジュール化し、追跡可能にし、小さく始める。そのどの原則も、失敗と引き換えに得たものである。