ほとんどのAIパイロット（PoC）は、アイデアが間違っていたから失敗するのではありません。確率的に動くシステムを、重要な業務の中で無人で動かすための仕組みを、誰も作らなかったから失敗します。デモが証明するのは、モデルがその作業を1回できることです。本番稼働が証明するのは、人がすべての誤りを拾わなくても、1万回できることです。
当社は、この2つの隔たりを5つの関門として扱っています。それぞれの関門は、システムを無人で動かす前に誰かが必ず尋ねる問いに答えるものです。どれも早い段階で作れば安く、後から付け足すと高くつきます。1つでも飛ばすと、パイロットは止まります。止まる場所はたいていエンジニアリングではありません。その関門が答えるはずだった問いに誰も答えられない、レビュー会議です。
5つの関門
| 関門 | 答える問い | 欠けているとどうなるか |
|---|---|---|
| 評価（eval） | 十分な品質か。その変更で良くなったのか | リリースのたびに感覚で議論することになる |
| 可観測性 | この案件で実際に何をしたのか | 怒った顧客から知らされる |
| ガードレール | 起こりうる最悪の事態は何か | セキュリティや法務の審査をいつまでも通らない |
| ロールバック | 使っているモデルが変わったらどうするか | ベンダーの更新で、気づかないうちに壊れる |
| 責任者 | これは誰の数字か | 委員会が承認し、誰も公開まで進めない |
関門1：重視する成果を測る評価セット
評価セットとは、正しい結果が分かっている実際の事例を固定の組にしたもので、何かを変更するたびに自動で採点します。抜き取り検査ではなく、「この出力は良さそうか」という確認でもありません。先週の数字と比べられる数字です。
これがなければ、品質は意見の問題になります。プロンプトを少し直すたびに議論になり、その変更が役に立ったのか誰にも言えず、測れないリリースに承認を出そうとする人もいません。これはモデルの問題ではなく、物差しがないという問題です。採点できないものは、公開できません。だからこそ当社はこれを他のすべてに先立つ関門と位置づけ、このテーマだけで記事を1本（英語）書いています。
通過の目安：モデルを入れ替えたり、プロンプトを書き直したりしたとき、品質が動いたかどうかと、その方向が数分で分かることです。
関門2：システムが実際に何をしたかを追える可観測性
集計のダッシュボードのことではありません。1回の実行ごとに追跡できる記録です。どの実行についても、入力、取得したコンテキスト、呼び出したツール、返した結果、かかった費用、かかった時間が分かる必要があります。
確率的に動くシステムは、静かに失敗します。決定論的に動くプログラムのバグはエラーを出しますが、モデルは少しだけ間違ったものを自信ありげに返し、そのまま動き続けます。トレース（実行記録）がなければ、こうした失敗は、積み重なって人が気づくまで見えません。1件のサポートのエスカレーションをきっかけに、1か月分の誤った出力が見つかるのはこのためです。
通過の目安：「先週の火曜日、この案件でなぜそうしたのか」という質問に、5分以内に答えられることです。
関門3：最悪の事態を限定するガードレール
エージェントが何に触れられるか、いくらまで使えるか、何を言えるか、いつ担当者に引き継がなければならないかを、明示的に制約します。範囲の制限はコードで強制するものです。プロンプトの中でお願いする指示ではありません。
実際にほとんどのパイロットが止まるのはこの関門で、止めるのがエンジニアリングであることはまれです。止めるのは、セキュリティ審査、法務審査、そしていつまでも結論の出ないリスクの議論です。影響範囲を一文で説明できる人がいないからです。「おそらく」正しく動くエージェントに、本番システムへの書き込み権限は与えられません。そのため、いつまでもデモのままになります。解決策は、起こりにくいと主張することではなく、最悪の事態を小さく、明確にすることです。
通過の目安：システムが起こしうる最悪の事態を一文で言えて、そのリスクに責任を持つ人が納得していることです。
関門4：前提が変わったときのためのロールバック手段
モデルのバージョンを固定し、プロンプトと設定をバージョン管理し、正常に動いていた状態にいつでも戻せるようにします。土台になっているモデルは、安定したインフラではありません。ベンダーは、貴社の都合ではなく自社の都合で、モデルを廃止し、調整し直し、挙動の変更を出します。
この関門を飛ばしたチームは、いつも同じ形でそれに気づきます。何か月も動いていたものが週末のうちに劣化し、戻れる以前の設定がありません。現在の設定を直接書き換えてきたからです。元に戻す作業は、一から導き出し直す作業になります。
通過の目安：ロールバックが作り直しではなく、1回のデプロイで済むことです。
関門5：指標に責任を持つ、名前の決まった担当者
1人の人と、1つの数字です。スポンサーでも、ワーキンググループでも、ベンダーでもありません。その数字が動くかどうかが自分の仕事に影響する、名前の決まった個人です。
最も技術的でない関門ですが、結果を最もよく予測します。委員会はAIプロジェクトを承認するのは得意ですが、構造上、公開まで進めることができません。8人に分散した責任は、あと一押しが必要な木曜日の午後6時に、誰も自分のものと感じない責任です。当社はこの失敗の型を「ステアリングコミッティ税」と呼んでいます。プログラムが止まることを示す、最も確かな兆候です。
通過の目安：何も調べずに、その人の名前と数字を言えることです。
多くが最初の90日でつまずく理由
失敗はたいてい、誰かが気づくずっと前に決まっています。最初の四半期のうちに、その時点ではどれも妥当に見える3つの判断によってです。
1か月目：戦略がユースケースの一覧になる。ワークショップで15件の候補業務が挙がり、期待の大きさで順位が付き、最も取り組みやすいものではなく、最も見栄えのするものが選ばれます。15件のうち、現時点で測定できるコストが紐づいているのはどれかを、誰も尋ねません。そのため、後で責任を負うべき数字がありません。
2か月目：指標に責任を持つ人がいない。プロジェクトにはスポンサー、ベンダー、ステアリングコミッティがそろっています。しかしそれは、数字が動くかどうかに自分の仕事がかかっている、名前の決まった1人がいることとは違います。委員会はAIプロジェクトを承認できますが、成功させることはできません。これが「ステアリングコミッティ税」であり、プログラムの停滞を最も確実に予測する要因です。
3か月目：デモが成功し、成功の定義がひそかに変わる。想定どおりの入力ではうまく動き、会議室は感心し、目標が「本番稼働」から「実演できた」へと静かにすり替わります。ここから先、プロジェクトは失敗するというより、終わらなくなります。企業の生成AIパイロットの95%が損益に測定可能な効果を出していない（MIT Project NANDA, 2025）のも、Gartnerがエージェント型AIプロジェクトの40%超が2027年末までに中止されると予測している（Gartner, 2025）のも、このためです。
対策は地味です。すでに誰かのコストになっている業務を1つ選び、指標に担当者の名前を付け、「完了」を、会議室を感心させたデモではなく、本番環境で無人で動いていることと定義します。当社の支援が、スライド資料ではなく実際に動くものの納品で終わる固定価格の2週間のスプリントから始まるのは、まさにこのためです。まだその手前の段階であれば、AI導入準備度の診断ツール（英語）のほうが、より安く済む最初の確認になります。
どの関門で止まっているか
止まったパイロットは、内側からはどれも同じに見えます。しかし症状は、たいてい欠けている関門をちょうど1つ指しています。
- 「調整を続けているのに、良くなっているのか分からない」。関門1です。物差しがありません。
- 「動くときは動くが、動かないときがあり、再現できない」。関門2です。トレースがありません。
- 「開発は何か月も前に終わったのに、まだ審査中だ」。関門3です。最悪の事態を誰も限定できていません。
- 「以前は動いていたのに、何かが変わった」。関門4です。戻るべき正常な状態がありません。
- 「重要だと全員が言うのに、何も進まない」。関門5です。数字に責任を持つ1人がいません。
この見立ては、思った以上に重要です。関門は上の順番で作れば安く、順番を外すと高くつくからです。すでに本番環境で動いているシステムに後から評価を付けるには、誰も記録していなかった事例から正解データを復元しなければなりません。障害の後で可観測性を加えても、記録のない出来事を調べることになります。当社に持ち込まれる高額な立て直し案件のほとんどは、最初に作れば数日で済んだ関門に、後付けの代償を払っているチームです。
特別なことは何もありません。10年前にWebのデモを信頼できるソフトウェアに変えたのと同じ規律を、たまたま非決定論的な技術基盤に当てはめているだけです。「PoC止まり」に陥っている企業に足りないのは、意欲ではありません。足りないのは関門です。Gigabit Agents（AIエージェント開発）の構築は、まさにその関門を組み込むためのものです。
