AIエージェントの事故は、モデルの性能不足よりも、権限、承認、評価の境界が曖昧なまま本番へ出した時に起きやすくなります。2026年8月時点では、OpenAI Agents SDK、Anthropic のガードレール文書、Google ADK の評価ガイドがいずれも『まず境界を設計し、その後に自動化範囲を広げる』流れを採っています。
AIハーネス設計とは何か？なぜ2026年に重要なのか
AIハーネス設計とは、エージェントが使えるツール、保持する状態、承認が必要な操作、実行ログと評価方法を先に定義する考え方です。モデルを賢くする話ではなく、エージェントを安全に再現可能な業務フローへ落とすための土台と考えると分かりやすいです。
OpenAI Agents SDK は agent、tools、guardrails、handoffs、human-in-the-loop、sessions という境界を明示しています。Google ADK も、prompt と tool call から始めて、必要に応じて graph workflows、evaluation、deployment へ拡張する構成を打ち出しています。つまり2026年の主流は、『最初から全部自律』ではなく『最初は単純、でも境界は明示』です。
この設計を先に入れると、PoC が当たった後に権限整理や監査設計をやり直すコストを減らせます。逆に、デモ優先で権限もログも曖昧なまま進めると、顧客データや本番システムを触る段階で止まりがちです。ハーネスはスピードを落とす仕組みではなく、広げるための前提条件です。
AIエージェントの設計方針や社内ルールを整理したい場合は、 お問い合わせはこちら 。PoC前の設計レビューから伴走できます。
どの権限を分離すると事故を減らせるのか
最初に分けたいのは、読む、書く、削除する、外部送信する、権限変更する、の5系統です。読むだけの調査エージェントと、更新を伴う実行エージェントを分けるだけでも、事故半径は大きく変わります。OWASP の AI Agent Security Cheat Sheet でも、least privilege と tool abuse 対策が基本として扱われています。
実務では『本番DBへ書き込めるが削除はできない』『Slack投稿はできるがメール送信はできない』『顧客情報は参照できるがエクスポートはできない』のように、業務単位で細かく権限を絞るのが現実的です。ツールごとに別トークンや別サービスアカウントを使うと、漏えいや誤実行の影響範囲を限定しやすくなります。
また、外部Webやメールなど untrusted content を読む系ツールは、更新系ツールと同じ実行ループに載せない方が安全です。Anthropic の indirect prompt injection 対策でも、第三者コンテンツは untrusted data として扱い、機密情報や強い権限から切り離すことが推奨されています。
承認フローはどこに置くべきか
承認は最後に一回だけ置くより、『投入前』『実行前』『公開前』に分けた方が機能します。投入前は個人情報や機密データをモデルへ渡してよいか、実行前は更新・送信・削除の内容が妥当か、公開前は顧客影響や外部公開が問題ないかを確認する役割です。
OpenAI Agents SDK の human-in-the-loop では、tools に needs_approval を付けて、敏感な操作だけを中断・承認できます。この考え方をそのまま業務設計へ写すと、『読む系は自動、送る系は承認』『軽微な更新は自動、公開は承認』のようなルールが作りやすくなります。
承認文面は『何を』『どこへ』『どの権限で』『失敗時にどう戻すか』の4点セットで固定すると、判断者の負荷が下がります。自然文の長い説明だけにすると、重要な破壊操作が埋もれやすく、承認の品質が安定しません。
評価手順はどう作れば“vibes”で終わらないか
評価では、最終回答の質だけでなく、途中の tool use trajectory まで見ます。Google ADK は agent evaluation を『出力』と『軌跡』に分けて説明しており、OpenAI Agents SDK も guardrail 結果や tool 実行の蓄積をログとして扱えます。つまり、正解したかだけでなく、どうそこへ至ったかを採点できる状態を作るべきです。
最低限そろえたい評価セットは、1) 成功してほしい代表タスク、2) 失敗させてはいけない禁止ケース、3) 承認待ちで止まるべきケース、の3種類です。各ケースで、完了率、不要ツール実行回数、再試行率、人手介入率、承認漏れ件数を取ると、改善の方向が見えやすくなります。
OpenAI の guardrails は blocking 実行と parallel 実行を分けており、コスト最適化や副作用回避が必要なら blocking が有効です。ここまで含めて評価すると、『正しく答えたが危険なツールを先に叩いていた』ようなケースも見逃しにくくなります。
評価テンプレートや社内レビュー表を整備したい場合は、 お問い合わせフォーム からご相談ください。PoCの時点で指標を揃えておくと、拡張判断がしやすくなります。
導入はどんな順番で進めるべきか
おすすめは4段階です。第1段階で対象業務を1つに絞り、必要ツールと禁止操作を一覧化。第2段階で権限分離と承認ポイントを設定。第3段階で評価セットと監査ログを整備。第4段階で初めてマルチエージェント化や自動公開範囲を広げます。この順番なら、見た目だけ動くデモに引っ張られにくくなります。
最初の対象業務は、社内FAQ、提案書の下書き、調査サマリー作成、チケット分類のような読み取り中心タスクが向いています。請求、顧客通知、本番データ更新のような不可逆操作は、最初から承認付きで設計した方が安全です。
Graph workflow や handoff は、業務が本当に分岐してきた段階で足せば十分です。単一エージェントで境界を守れない状態のまま複雑化すると、評価と障害解析のコストだけが上がります。
よくある質問：最初からフレームワークやマルチエージェントは必要か
結論から言えば、最初から必須ではありません。2026年の主要ドキュメントも、単純な prompt + tools から始め、必要なら graph、handoff、workflow へ拡張する順番を勧めています。最初の目的は『高度な構成を採用すること』ではなく、『業務を安全に再現できること』です。
承認が多すぎて遅くなるのでは、という不安もよくありますが、読む系を自動化し、不可逆操作だけ人が握る構造にすると、速度と安全性を両立しやすくなります。全部を止めるのではなく、止めるべき場所だけを明確にするのがハーネス設計です。
つまり、最初に必要なのは豪華なフレームワークではなく、権限境界、承認ルール、評価指標、監査ログです。この4点が揃うと、あとからどのSDKやモデルへ移っても設計資産が残ります。
AIエージェントの設計レビューや社内研修の相談は、 お問い合わせはこちら 。権限設計から評価運用までまとめて支援できます。
