AIエージェントは「動かす年」へ。PoC止まりを抜ける運用3条件

ChatGPTもClaude Codeも触った。AIエージェントを試しに1体作ってみた人も増えました。次に来る問いはこれです。「で、その1体、いまも動いていますか？」

止まったまま放置されているケースが、僕の周りで急増しています。理由は1つではない。プロンプトの問題でも、モデルの問題でもなく、運用設計が最初から抜け落ちていることが本丸です。

IBMは2026年を「企業がAIエージェントを”作る”のをやめて、“動かす”年」と表現しました。日本語で読める解説はほぼ出ていない。けれどこのフレームは、PoCで止まった担当者にとって今いちばん効きます。

IBMが提起した「動かす年」というフレームを起点に、AIエージェントを運用に乗せるための3条件を整理します。今週直すべき1つの設計ミスと、7日以内に着手できる3アクションまで持ち帰れる形にしました。

本記事の事実ラベル方針 マサゴからの直近指摘（2026-05-25）を踏まえ、本記事では「公式確認済み事実」「他社引用」「ナギの実運用経験から導いた仮説」を明示的に分けて記述します。混ぜません。

なぜ「動かす年」というフレームが効くのか

AIエージェント関連の記事は、ここ半年ほど「作り方」「ツール比較」「事例紹介」に集中していました。読者である僕自身、Claude CodeとMCPサーバーを組み合わせて出雲という自律ワークフローを動かしています。記事を書く側の人間も、運用側に立ったときの感覚はあまり共有してこなかった。

IBMが「動かす年」と表現した背景には、3つの観測事実があります。1つ目は、PoC（概念実証）から本番運用に進めなかった企業が想像以上に多いこと。2025年後半から、AIパイロットの多くが成果に届かない要因として「インフラではなく運用設計の欠落」を指摘する論考が、複数のAI研究者やコンサルティング機関から相次いでいます。特定の一次ソースではなく、業界全体の観察から導いたものとして受け取ってください。

2つ目は、Anthropicが2026年5月「Claude for Small Business」を公開したこと。中小企業向けに15種類のready-to-run workflowsを揃えた発表で、個別のエージェントを”作る”時代から、用意されたものを”動かす”時代への明確なシグナルです（Anthropic公式ニュース、2026-05-23）。

3つ目は、HBRが2025年6月の特集で「AIエージェントのリスクに組織は備えられていない」と提言したこと。組織として対処するとは、観測し、フィードバックを与え、引き継ぎを設計するという意味です。これも運用観点の話になります（“Organizations Aren’t Ready for the Risks of Agentic AI”, HBR 2025年6月）。

3つを並べると、業界全体が同じ方向を見ているのが分かります。作るのは終わった。動かす段階に入った。

ここで重要なのは、「動かす」は「ほっとけば動き続ける」ではないという点です。AIエージェントは放っておくとサイレントに壊れます。応答内容が少しずつズレる、外部APIの仕様変更で1つのステップだけが失敗する、入力データの傾向が変わって出力品質が落ちる。誰も気づかないうちに価値を出さなくなる現象が起きます。

これが、PoCで止まった担当者がぶつかっている壁の正体です。「動かない」というより「動かしている自覚がない」状態に近い。

[[IMG:1]]

ここから先は、僕がClaude Codeと出雲システムを実際に運用するなかで形成した仮説です。IBM公式の文言を直接引用したものではありません。「IBMが提起したフレームを、ひとり〜小規模チームの実務に翻訳するとこうなる」という整理として読んでください。

運用に乗せるための3条件

僕が考える運用3条件は次の3つです。観測・修正・引き継ぎ。

[[IMG:2]]

条件1: 観測（Observability）— 止まったときに気づける状態

最も基本的で、最も飛ばされやすい条件です。エージェントが何を入力に取り、何を出力し、どこで失敗したかをログとして残す。これがないと、運用は1日目から始まらない。

僕が出雲で最初に組んだのは、各エージェントの実行ログを1つのファイルに集約する仕組みでした。実行時刻、入力サマリ、出力サマリ、エラーの有無の4つだけ。これだけで「昨日は3体動いた、今日は2体しか動いていない」が分かるようになります。

観測を仕込んでいないPoCには、共通する症状があります。「動いていることになっている」状態。週次レビューで「順調です」と報告されているのに、内部のログを開くと半分は失敗していた、というケース。経験上、観測なしの運用は3週間以内に崩壊することが多い。これは実運用から得た経験則であり、定量的な調査ではありません。

ここで気になるのが「観測のためのツールは何を使うのか」ですよね。最初は何でもよいです。ファイル1つで十分。LangSmithやLangfuse（どちらもLLMアプリ向けのモニタリングツール）のような専用ツールはあるけれど、それを入れる前に「自前で4列のログファイルを書き出す」ところから始めるのが現実的です。ツールに依存すると、ツール選定で止まる。これも実体験です。

条件2: 修正（Iteration）— 崩れたら直せる状態

観測ができても、直せなければ意味がない。ここが2つ目の条件です。

エージェントの出力品質が落ちたとき、原因の切り分けが「プロンプト」「モデル」「ツール（外部API）」「入力データ」のどれかは見えるようになっていますか？ もし出力結果しか手元になければ、修正は当てずっぽうになります。

僕の出雲システムでは、各エージェントの出力に対して「マサゴ」というレビュー専用エージェントが3ラウンドのフィードバックを返します。ここで重要なのは、レビューが指摘の根拠ごと残っていること。1ヶ月後に同じ症状が出たとき、過去のレビューを検索して「同じ問題が3月にもあった、対処はプロンプト修正だった」と引ける状態にしておく。

これがないと、毎回ゼロから原因究明をやり直すことになります。エージェントは1体ではない。10体、20体と増えたとき、修正履歴がないと運用が物理的に回らなくなる。

修正の手順化は、テンプレ1枚で十分です。「症状」「観測した数値」「仮説」「打った手」「結果」の5列。これだけ。複雑な障害管理ツールは、規模が大きくなったら考えればよい。

条件3: 引き継ぎ（Handover）— 自分以外でも動かせる状態

3つ目で、最もスキップされる条件です。エージェントを動かしているのが自分1人だと、運用は自分の頭の中にしか存在しなくなる。

僕は出雲で、各エージェントに「SoulDocument」というドキュメントを必ず添えています。役割、判断基準、過去の失敗例、避けるべきパターン。これを読めば、僕以外の人間がそのエージェントの設計意図を理解できる状態を作っています。

引き継ぎがないと、エージェントは作った本人が辞めた瞬間にブラックボックスになります。技術的な問題ではなく、組織的な問題として扱う必要がある。

SoulDocumentに最低限書くべき項目は5つだけです。役割、入出力、判断基準、過去の失敗例、避けるべきパターン。それぞれ短く、1ページに収まる分量で十分です。詳細はあとから足せばよい。最初の1ページがあるかどうかで、エージェントが組織の資産か個人の道具かが分かれます。

[[IMG:3]]

PoC止まりの3症状を整理すると、停止に気づかない（観測の不在）、崩れたら作り直し（修正の不在）、属人化（引き継ぎの不在）、の3つに対応しています。1つでも欠けると、エージェントは運用に乗りません。3つ揃って初めて「動かす」が成立する。

3条件はなぜ抜けやすいのか

3条件を聞くと「当たり前のことしか言っていない」と感じるかもしれません。僕も最初はそう思っていました。

抜ける理由は単純で、3条件のどれも作っているときには必要を感じないからです。プロトタイピング段階ではエージェントが目の前で動いている。ログを見るまでもなく、出力を直接確認できる。修正もその場でプロンプトを書き換えれば済む。引き継ぎは、まだチーム化されていない。

問題は、PoCが終わって「本番運用に入ろう」と決めた瞬間に、観測も修正記録も引き継ぎドキュメントも何1つない状態であることに気づくことです。そこからゼロで作り始めるのは、心理的にきつい。だから先送りされて、結局PoCで止まる。

最初から3条件を仕込んで作ること。これが「動かす年」の本質だと、僕は理解しています。

PoC止まりの本当の原因

ここまで読んで、「ツール選定の話」や「プロンプトの巧拙」を期待していた方は拍子抜けかもしれません。けれど僕が実運用で見てきた限り、PoCで止まる本当の原因は、運用設計の不在以外にほぼないです。

技術的な失敗は、ほとんどの場合プロンプト調整や別ツール移行で解決します。問題はその後。動かし続けるための仕組みが組まれていないと、3週間後には「あれ、まだ動かしてたっけ？」になる。

実例を出します。僕が知っているある企業のマーケチームでは、Claude Codeで議事録要約エージェントを作りました。3週間は順調に動いていた。けれど4週目に入って、Zoom側のAPI仕様が一部変更され、特定の会議タイプだけ要約が空になる現象が起きました。担当者は気づかなかった。3ヶ月後に上司が「最近、要約の精度が落ちた気がする」と言ったとき、初めて壊れていたことが判明した。

ここで起きたのは、技術の失敗ではなく、運用の失敗です。観測がなければ、3ヶ月間サイレントに壊れたまま使い続けることになる。

この種の事例は、規模を問わず大量にあります。中小企業でも大企業でも同じ。エージェントの数が増えるほど、観測なしの運用は加速度的に厳しくなる。

ちなみに僕は出雲システムで現在11体のエージェントを動かしています。観測ログがなければ、毎朝「今日は何体が正常に動いたか」すら把握できない。月次の改善は完全に勘になる。ログを取り始めてから、週次で「今週はこの2体の出力品質が落ちている」と数字で言えるようになった。意思決定の質がまったく違う。ツールの違いではなく、観測の有無で決まる。これも経験則ですが、出雲11体の実測から来ています。

自分のPoCがどの症状に当てはまるか

3つの症状の中で、自分のエージェントがどれに該当しているかを確認してみてください。

1つ目: 過去1ヶ月、そのエージェントの出力が正しいかを自分の目で1件以上確認しましたか。していなければ、観測が不在です。

2つ目: 前回エージェントが期待外れの出力を返したとき、どこの何を変えれば直るかを5分以内に判断できましたか。判断できなければ、修正の仕組みが不在です。

3つ目: 自分が1週間休んだら、そのエージェントは止まりますか。誰か別の人が面倒を見られる体制になっているかを確認してみてください。誰も見られないなら、引き継ぎが不在です。

3つのうち1つでも引っかかったら、運用設計を入れる必要があります。3つとも引っかかった場合は、いったんエージェントを止めて運用設計を組み直したほうが速い。これは僕自身、過去に何度もやり直してきたパターンです。

今週直すべき1つの設計ミス

3条件を全部いちどに整えるのは現実的ではない。だから「今週直すならどれか」を1つ選びます。

観測だけは今週中に必ず入れてください。

理由は単純で、観測がなければ修正も引き継ぎも成立しないからです。修正はログがあって初めて打てる。引き継ぎドキュメントは観測の歴史を踏まえて書ける。観測は3条件の土台です。

しかも観測は、最も実装が軽い条件でもあります。ファイル1つに4列書くだけで始められる。クラウド契約も新ツールの選定も不要。今週で確実に1巡できる。

ここで気になるのが「観測って具体的に何を記録するのか」だと思います。最小構成は次の4列です。

列	内容
実行時刻	YYYY-MM-DD HH:MM形式で十分
入力サマリ	入力の要旨を1〜2行
出力サマリ	出力の要旨を1〜2行。または出力ファイル名
エラー有無	OKかNGの2値、NGの場合は短いメモ

これだけです。複雑にしない。複雑にすると、毎日記録する気力がなくなって運用が止まる。シンプルさは正義です。

7日以内に着手する3アクション

今週中に動かせる3アクションを整理しました。順序は固定です。

[[IMG:4]]

アクション1（Day1-2）: 観測点を1つ決める

エージェントが何をしているのかを、4列のログとして残す仕組みを今週前半で組みます。

具体的には、エージェントの実行スクリプトに「実行結果を1行追記する」処理を追加するだけ。1ファイルでよい。Spreadsheetでもテキストファイルでもよい。場所を決めて、必ず追記される状態を作ってください。

Claude Codeを使っているなら、エージェント定義ファイルの最後に「実行ログをlogs/agent-name.logに追記する」と1行加えればOK。30分以内に終わる作業です。AIエージェントの基本的な作り方についてはAIエージェントの作り方3ルートで整理しています。「作り方を理解した上で運用設計を入れる」が、この記事との使い方の順序です。

アクション2（Day3-4）: 修正テンプレを作る

5列（症状・観測値・仮説・打った手・結果）のテンプレを1枚用意します。Notion、Obsidian、Markdownファイル、何でもよい。

最初の3日間で気づいた異常を1件、このテンプレに書いてみてください。書けない場合は、観測ログをもういちど見直しましょう。観測値が足りない可能性があります。

アクション3（Day5）: 引き継ぎドキュメントの1ページ目を書く

エージェントごとに「このエージェントは何を入力に取り、何を出力するか、判断に迷うときは何を優先するか」を1ページにまとめます。詳細は要らない。30分で書けるレベルでよい。

僕の出雲では、これをSoulDocumentと呼んでいます。1ページ目さえあれば、僕以外の人間が「このエージェントは何のためにいるのか」を理解できる。それで十分です。

Day6-7: 最初の1巡を回す

3アクションが揃ったら、Day6-7で1巡回します。観測ログを開き、異常があれば修正テンプレに書き、引き継ぎドキュメントに学びを反映する。

この1巡を一度経験すると、運用設計が自分の習慣として身体に入ります。次の週からはこの1巡を週次で回す。これがAIエージェントを「動かす」という意味です。

Claude Codeの基本的な料金や導入コストを知りたい方には「claude codeの料金、結局いくらかかるの？」も参考になります。予算感を把握した上で運用設計を組むと、投資対効果の見通しが立てやすくなります。

まとめ

AIエージェントは「動かす年」に入りました。作るのは終わった。次に来るのは「動かし続ける」ための運用設計です。

ここまでで整理した3条件をもういちど並べておきます。

• 観測：止まったときに気づける状態。4列のログから始める
• 修正：崩れたら直せる状態。5列のテンプレで履歴を残す
• 引き継ぎ：自分以外でも動かせる状態。1ページのドキュメントから始める

今週直すなら観測です。観測は土台で、これがないと修正も引き継ぎも成立しません。30分で組めます。今週中に着手してください。

エージェントを「作ったのに動かしていない」のは、技術力の問題ではない。運用設計が抜けているだけです。3条件を仕込めば、PoCで止まったエージェントは動き始めます。

「動かす年」は始まっています。今週、最初のログを1行書くところから動いてみてください。