Claude Codeの責任経路を徹底解説。開発者が本番環境のAI運用で負うべきリスクと設計の正解

AIエージェントが「動く」だけの時代は終わった。

AIエージェントがコードを書き、伝票を作り、マスタを更新する。

そんな光景が当たり前になっている。

開発者が直面しているのは、もっと泥臭い現実だ。

「AIが勝手にやった」では済まされない責任の所在。

便利さの裏側で、AIの判断をどう証明するかが課題だ。

責任経路（Responsibility Pathway）の設計。

これができない開発者は、本番環境の運用から外れる。

何が起きているのか。

開発はどう変わるのか。

数字と事実から、その正体を見極める。

AI実行環境の二極化と「責任」の重み

AI活用の現場では、二極化が進んでいる。

ローカルLLMによる「低コスト・高速・プライバシー重視」の潮流。

エンタープライズ基盤における「監査・権限・証跡管理」の重厚な設計。

Ollamaのようなツールで、ローカル環境でのモデル実行が容易になった。

Gemma 3のような最新モデルを、自分のPC上で量子化（Q4_K_Mなど）された状態で実行できる。

4B（40億パラメータ）程度の軽量モデルであっても、特定のタスクではGPT-4oに匹敵する精度を出すという報告がある。

ローカルLLMのメリットは明確だ。

運用コストはほぼゼロになる。

ユーザーのデバイスリソースを使うため、クラウドへのAPIリクエスト料金が発生しない。

通信が発生しないため、実行速度が速く、プライバシーも守られる。

しかし、これをERP（基幹系システム）のような領域に持ち込むと話は一変する。

企業の会計、購買、在庫、人事といった、失敗が許されないデータが詰まっているからだ。

AIを業務システムに接続することは、単なる機能追加ではない。

企業の責任経路にAIを組み込むことそのものだ。

AIがマスタ変更を提案し、人間がそれを承認し、システムが実行する。

この一連の流れにおいて、誰が、いつ、何の根拠でその判断を下したのか。

証跡（Evidence Log）が残らなければ、監査に耐えることはできない。

開発者の間では、LangGraphのようなライブラリを使って、AIの状態（State）を保持し、Human-in-the-loop（人間の介入）を組み込む設計が注目されている。

また、Model Context Protocol（MCP）のように、AIアプリと外部ツールを標準化された方式で接続する試みも始まっている。

しんたろー：
ローカルLLMの進化が速い。
手元のMacでサクサク動くのを見ると、クラウドAPIのコストが気になる。
仕事で使うとなると「AIが間違えたら誰が責任取るの？」という壁にぶつかる。
開発者がその「言い訳の証拠」をシステムとして作る必要がある。

開発者が設計すべき「責任経路工学」の正体

開発者が学ぶべきは「AIの賢さ」ではなく「責任経路の設計」だ。

これを、理論・設計・実装の三層で整理する考え方が浮上している。

理論層では、AIがどの範囲まで判断を下して良いかの境界線を決める。

設計層では、AIの提案を人間がどう確認し、どこで止めるかのフローを構築する。

実装・監査層で、実際のログや権限、障害対応の仕組みを作り込む。

特に重要なのが、マスタデータへの影響だ。

得意先や仕入先、品目価格といったデータは、後続のあらゆる業務の起点になる。

AIが「マスタ変更案」を出したとき、以下の項目が設計されている必要がある。

• AIは提案のみか、更新まで行うのか
• 変更前後の差分が明確に表示されるか
• 承認者はその業務の責任を持っているか
• 誤変更が発生した際、ロールバック（差し戻し）ができるか
• 変更履歴が、AI側のログとシステム側のログで紐付いているか

これらが欠けた状態でAIを導入するのは、ブレーキのない特急列車を走らせるようなものだ。

Claude Codeのような高度なエージェントツールを使うと、開発のスピードは上がる。

しかし、そのツールが「なぜそのコードを書いたのか」「どのファイルを書き換えたのか」という履歴を、業務の監査ログとどう統合するかという視点が、エンタープライズ開発では不可欠になる。

AIが生成したAI Request IDと、業務システムの伝票IDを紐付け、後から「あの時、AIはどう判断したのか」を再現できるようにしなければならない。

これをEvidence Log（証跡ログ）の接続と呼ぶ。

技術的には、チェックポイント機能を使って、AIの思考プロセスを途中で保存し、人間がその時点からやり直せるような設計が求められている。

単に「結果」だけを受け取るのではなく、AIの「過程」を管理下に置くということだ。

しんたろー：
ログの紐付けは地味だが重要だ。
本番環境で障害が起きた時に「AIが勝手にやりました」と言えば、開発者としての信頼に関わる。
Claude Codeで開発するのは最高だが、その裏で「証拠」を残す仕組みを考えるのがプロの仕事だ。

本番環境で負うべきリスクと実務への影響

結論として、「AIの提案＝人間の責任」という構造を、システムとして強制する設計が必要になる。

AIが請求書を読み取り、入金消込の候補を出す。

デモでは魔法のように見えるが、本番では例外処理が必ず発生する。

その際、AIが「たぶんこれです」と出した提案を、人間が中身も見ずにクリックする「形骸化した承認」が最大のリスクだ。

これを防ぐためには、承認画面でAIの推論根拠を強調表示したり、重要な項目にはあえて手入力を求めたりする工夫が必要になる。

これを摩擦の設計と呼ぶ。

効率化のためにAIを入れるのに、あえて人間に手間をかけさせる。

この矛盾こそが、責任を担保するための鍵になる。

運用コストの面でも変化が起きる。

クラウドLLMを使い続ける場合、トークン料金だけでなく、SLA（サービス品質保証）やデータ保護の契約コストが重くのしかかる。

一方で、ローカルLLMを自前サーバで動かす場合は、初期投資とメンテナンスの手間が発生する。

開発者は、プロジェクトの性質に応じて、これらを使い分ける。

• 機密性の高い社内データの整理：ローカルLLMで閉じた環境を構築。
• 外部との取引が発生する業務プロセス：クラウドベースの強固な監査基盤を持つAIエージェントを採用。

この二段構えのスキルセットが、これからの開発者の標準装備になる。

さらに、障害対応の考え方も変わる。

AIが関与した障害では、バグの特定が困難になるケースが多い。

「モデルの出力が揺らいだのか」「プロンプトが悪かったのか」「外部データの不備か」。

これらを切り分けるために、AIへのリクエスト時のプロンプト、モデルのバージョン、参照したデータをすべてセットで記録しておく必要がある。

しんたろー：
承認ボタンを「ただのボタン」にしない設計が難しい。
人間は楽な方に流れるため、AIが「OKです」と言えば信じてしまう。
あえて疑わせる、あるいは責任を自覚させるUIを作るのが、フロントエンド開発の面白いところだ。

AIエージェント運用のためのFAQ

Q1: ローカルLLMとクラウドLLM、どちらを優先すべき？

タスクの性質で判断する。

非構造データの整理や簡単なRAG（検索拡張生成）など、データ流出リスクを避けたい、あるいはコストを抑えたいタスクにはローカルLLM（Ollama等）が最適だ。

特に、通信環境が不安定な場所や、大量のデータを低コストで処理したい場合には圧倒的な優位性がある。

一方、ERPなどの業務システムに接続し、承認や監査が必要なプロセスには、責任経路が明確に設計できるクラウドベースのAIエージェント基盤を採用する。

ログの追跡性や、ベンダーによるセキュリティ保証が必要な場面では、クラウドの方が結果的にリスクが低くなる。

Q2: AIエージェント導入時に最も見落としがちな点は？

「AIが提案した後の責任の所在」だ。

デモではAIが自動で伝票を作る様子が映えるが、本番環境では「AIの提案を人間がどう確認し、どのログが証跡として残るか」を設計しないと、誤ったデータ入力や不正なマスタ変更が発生した際に修復不能になる。

AIを導入する際は、必ず人間が責任を持って介入できるHuman-in-the-loopのポイントを業務フローに組み込む。

また、AIの判断を後から検証できるように、推論時のコンテキスト（参照データやプロンプト）を保存する仕組みを最初から設計に入れておく必要がある。

Q3: 開発者のスキルセットはどう変わる？

「プロンプトが書ける」以上の能力が求められる。

これからの開発者は、AIを単なるAPIとして叩くのではなく、システム全体のガバナンスを設計する能力が必要だ。

具体的には、LangGraphのような状態管理ライブラリの習熟、MCPによるツール接続の標準化、そして監査ログのデータモデリングだ。

AIが生成した非構造なデータと、業務システムの構造化されたデータをどう紐付け、一貫性を保つか。

この「橋渡し」ができる開発者が、AI時代のアーキテクトとして重宝される。

結局、僕らは何をすべきか

AIエージェントは、開発を10倍速にする。

Claude Codeなしでは、コードを書きたくないほどだ。

しかし、そのスピードに魂を売ってはいけない。

爆速でゴミを量産したり、誰にも説明できないコードを本番にデプロイしたりするのは、プロの仕事ではない。

責任経路を設計すること。

AIの判断に、人間の証跡を刻むこと。

地味で面倒なこの作業こそが、AIを本当の意味で「使いこなす」ということだ。

まずは、自分の作っているシステムで「AIが間違えた時、誰がどうやって直すのか」を想像する。

そこから、君の責任経路工学が始まる。

👉 ThreadPostでSNS運用を自動化する