TL;DR

AIのインシデントは、AIそのものよりもガードレールや運用設計の不足で発生することが多い。

AI活用には「業務ドメイン知識」と「AIの特性・限界の理解」の両方が必要
AIは万能な実行者ではなく、ルール・権限・評価基準の範囲で動作するシステム
スキルやプラグインは増やすほど良いわけではなく、最小構成から始める方が安全
問題発生時に切り分けできるよう、各機能の責任範囲を理解しておくことが重要
報告フォーマットやチェックリストを標準化すると、人間とAI双方の認知負荷を下げられる
AIを使いこなす力以上に、「AIが安全に働ける環境を設計する力」が重要になる

結論：AIを疑うのではなく、AIを守る。

AI時代に求められるのは、優秀なプロンプト作成者ではなく、AIが継続的に成果を出せる環境を設計・運用できる人材である。

目次

はじめに：前編のおさらい
1.AIは本当に「実現手段」なのか
2.AIを疑うのではなく、AIを守る
最後に：前後編のまとめ

はじめに：前編のおさらい

こんにちは。MSOL DigitalでITコンサルタントとして活動しておりますuenoです。

前編では、ポケモンカードAIコンペへの挑戦を通じて遭遇した、三つの「怖い話」を紹介しました。

作業を終えられず修正ループに陥るAI
ツール同士が競合し、状態を壊しかけるAI
テストの抜け穴を利用して目的達成を図るAI

これらの事象を通じて見えてきたのは、『AIは敵ではない。しかし、放置すると想定外の方向へ進むことがある。』という事実でした。

そして、これはポケモンカードAIコンペのような特殊な環境だけの話ではありません。

業務システム開発、データ分析、運用自動化、AIエージェント開発など、AIが自律的に作業を行う場面が増えるほど、「AIに何をさせるか」だけではなく、「AIをどう監視し、どう制御するか」が重要になります。

むしろ多くの場合、

どこまで変更してよいのか
何を絶対に変更してはいけないのか
どのような手順で作業するべきなのか
問題が起きたときに誰が止めるのか

といったルールや仕組みの理解不足が本質的な問題です。

本稿では、実際のコンペ期間中に試行錯誤した経験をもとに、

AIエージェントを暴走させないためのガードレール
リワードハッキングを防ぐための設計
プラグインやスキルを増やしすぎない考え方
AI自身によるセルフチェックの仕組み

について紹介します。

1.AIは本当に「実現手段」なのか

前編で取り上げた怖い話（インシデント）も、振り返ってみるとAIそのものの性能不足だけが原因ではありません。

一つずつ対策をすることで100％とは言い切れませんが未然に防ぐことが可能です。下記はその一例です。

AIを使ったワークフロー（ここでは業務のやり方やノウハウとします）のルールを決める
プラグインを一切採用しない
採用するけど何かあったら切る or 会社の規模に合わせてリバースエンジニアリングする
コミュニケーションコストを減らすために報告のスタイルをスキル化・ルール化して対応させる

しかし、期待される役割は大きいものの「実現手段」として片づけられることが多いです。なぜ多いのか、次の節から考えていきたいと思います。

1-1. 期待と現実のギャップ

多くの企業がAI導入を検討する際に期待するのは、

売上向上
コスト削減
新規事業の創出
意思決定の高度化
業務プロセスそのものの変革

といった、ビジネス上の大きな成果です。

AIは単なる便利ツールではなく、企業競争力を左右する「実現手段」として語られることも増えました。

しかし現実を見ると、AI活用の多くは依然として個人レベルの効率化に留まっています。

例えば、

ミーティングの文字起こしと要約
メールやレポートの文章校正
PowerPoint資料の見映え調整
プログラムコードの補完
壁打ち相手としての利用

といった用途です。

もちろん、これらの活用自体に価値がないわけではありません。実際に作業時間が短縮され、日々の業務負荷が軽減される効果はあります。

現在のAI活用は、

「組織変革のための実現手段」として期待されている状態
「個人業務を効率化するツール」として利用されている状態

この2つの間に大きなギャップが存在していると言えるでしょう。

こうしたギャップが生まれる背景には、少子高齢化による人手不足や、限られた人数で成果を出さなければならない経営環境があります。

企業はAIに対して、人手不足を補い、業務そのものを変革することを期待しています。

一方で、AI導入の第一歩は比較的小さな単位の業務改善から始まることが多く、まずは文章作成や要約、資料作成といった個人業務の効率化に活用される傾向があります。

その結果、本来期待されていた「事業成果の創出」と、実際に得られている「時間短縮や作業効率化」が同じ文脈で語られやすくなっているのです。

1-2.なぜドメイン知識なのか？

AIを実務で活用するときに必要なのは、対象業務の知識だけではありません。

AIがどの情報を参照しているのか
どこまで判断できるのか
どのような制約を持っているのか
どこから先を人間が判断するべきなのか

を理解する必要があります。

これは、ポケモンの世界に置き換えるとわかりやすくなります。
ポケモンマスターを目指すなら、ただポケモンを戦わせるだけでは足りません。

タイプ相性、技、道具、育成、相手の傾向などを理解してはじめて、状況に応じた判断ができるようになります。

たとえば、ヒトカゲにみずてっぽうを覚えさせることはできません。

これは、AIに対して「できないこと」を期待してしまう状況に似ています。対象の性質や制約を理解しないまま指示を出しても、期待した結果は得られません。

また、対戦相手の情報やタイプ相性を確認せず、経験や勘だけで戦うことも危険です。

現実の業務でも同じで、

データを確認しない
ログを見ない
評価指標を定義しない
AIの根拠を検証しない

といった状態では、成果の良し悪しを正しく判断できません。

つまり、AIを業務成果につなげるためには、

業務ドメインを理解する力
AIの特性や限界を理解する力

の両方が必要になります。AIの知識だけでは、業務上の価値が判断できません。

AIは万能の実行者ではありません。与えられた情報、目標、評価基準の範囲で動作するシステムです。
だからこそ、人間側が「何を見せるのか」「何を任せるのか」「どこで止めるのか」を設計する必要があります。

1-3.クラウド開発は有効。ただし検証とガバナンスが前提

一方で、クラウド開発そのものは非常に有効です。

EC2上の開発環境
Web版Claude Code
Web版CursorのCursor Agent

これらを組み合わせれば、AIが課題の分析から実装、テスト、Pull Request作成までを支援できるようになっています。

場合によっては、人間が会議に参加している間や就寝している間にも作業が進むため、開発速度を大きく向上させることが可能です。

GitHubと連携すれば、

Issueの読解
作業計画の立案
コード実装
Pull Request作成
レビュー補助

といった一連の流れをAIが支援することもできます。

しかし、ここで一つ注意しなければならないことがあります。AIがコードを書けることと、その変更を安全に本番へ近づけられることは別問題です。

たとえばAIが作成したコードがテストを通過しているか、セキュリティ上問題ないかといったことは別途検証しなければなりません。

また、本番環境へ影響を与えるシステムでは、

CI/CD
権限管理
ブランチ保護
レビュー手順
ロールバック手順
監査ログ

といった運用上の仕組みも重要になります。

特に注意したいのは、「このツールを使わないと遅れている」「全部自動化できる」といった言葉だけが先行する状況です。
以下のようなサムネイル、誰もが見たことがあるのではないでしょうか？

新しい技術やサービスを試すこと自体は重要ですが、

どのような条件で検証したのか
どこまで有効なのか
失敗した場合どう戻すのか
誰が責任を持つのか

まで含めて設計されていなければ、実務で安全に運用することはできません。

つまり、AIエージェントやクラウド開発の本質は「人間を不要にすること」ではなく、「適切な管理のもとで人間の能力を拡張すること」にあるのです。

乗り遅れないためという理由で、急いで使いにくいツールを導入・購入する必要はありません。リリースされて日が浅いうちから使うような人間は私のような変態で十分です。

実現手段と個人最適化を行き来している理由はここにあると思われます。

2.AIを疑うのではなく、AIを守る

Databricksではエージェントを「モデル＋ハーネス」と捉えます。

しかし、今回の経験を踏まえると、実務で必要なのは「モデル×ハーネス×ガードレール（仮称）」だと感じています。

どれほど優秀なAIでも、実装や運用にマイナス要因があれば成果は負の方向へ引っ張られます。数学で正の数と負の数を掛けると負になるのと同じです。

もちろんAIに任せてよいことはたくさんあります。

一方で、トークンが尽きるまで失敗させない、スコープ外まで対応させない、変更範囲の境界を越えさせない、といった制御は人間が設計しなければなりません。

2-1.AIを使ったワークフローのルールを決める

AIは与えられた目標に向かって行動しますが、その過程までは自動的に保証してくれません。

たとえば、

どのブランチで作業するのか
テストはいつ実施するのか
PRは誰がレビューするのか
本番反映は誰が承認するのか

といったルールが存在しなければ、同じAIでも品質は大きく変わります。下記はそのためのワークフロー例となります。

2-2.まずは最小構成で始める

AIエージェントを取り巻くシステムは1つだけではありません。

モデル
RAG
スキル
プラグイン
システムプロンプト

このような複数の要素が組み合わさってパフォーマンスがいいAIエージェントができています。
しかし最初から大量にプラグインやスキル、プロンプトといった要素を追加すると、指示競合、コンテキスト競合、ツール競合が発生します。

その結果、本来なら短時間で実行できるタスクに対しても

意図しない無限修正ループ
意図しないツール実行
意図しない品質低下

が起こります。

だからこそ、最初は最小構成で始めることが重要です。

2-3.プラグインの責任範囲を理解する

AIエージェントを活用していると、

スキル
プラグイン
MCP
RAG
システムプロンプト

など、さまざまな機能を追加したくなります。

実際、それぞれを適切に組み合わせることでAIの能力を大きく拡張できます。

しかし、ここで注意しなければならないのは、これらの仕組みもまた一つのソフトウェアであるということです。

どれほど便利なツールであっても、バグや設計上の制約から完全に自由ではありません。

人間同士のシステム開発でも、利用しているOSSやライブラリについて最低限の役割や制約を理解するように、AIエージェントの周辺機能についても責任範囲を理解する必要があります。

たとえば、不具合が発生した際に

モデルの問題なのか
プロンプトの問題なのか
スキルの問題なのか
プラグインの問題なのか

が切り分けられなければ、適切な対処を行うことはできません。

また、プラグインを大量に導入している状態では、どの機能がどの動作に影響しているのか分からなくなることもあります。

前節で述べた「最小構成から始める」という考え方は、まさにこの切り分けを容易にするためのものです。これはアジャイル開発と同じ考え方です。

また、AIエージェントにもメンテナンスする機能が備わってます。例えばClaude Codeには/doctorコマンドが用意されており、現在の設定や構成に問題がないかを確認できます。

備わっている診断機能を活用することで、設定ミスや環境依存の問題を早期に発見できる場合があります。

組織でAI活用を進める場合は、自社独自のプロンプトやテンプレートについても定期的な棚卸しを行うことをおすすめします。

「なぜそのルールが存在するのか」まで行かなくても「他のルールと競合していないか」を確認するだけでもインシデント予防・不要な複雑化を防ぐことができます。

AIの性能向上ばかりに注目しがちですが、実務では「追加すること」よりも「不要なものを取り除くこと」の方が効果的な場合も少なくありません。重要なのは、多くの機能を導入することではなく、それぞれの責任範囲と影響範囲を理解した上で運用することなのです。

AI運用の定期点検チェックリスト例


#### ルール・プロンプト

- [ ] このルールの作成目的を説明できる
- [ ] 作成者または責任者が明確になっている
- [ ] 最終更新日が分かる
- [ ] 現在の業務と整合している
- [ ] 他のルールと競合していない
- [ ] 重複したルールが存在しない

#### スキル・テンプレート

- [ ] 利用目的を説明できる
- [ ] 利用頻度を把握している
- [ ] 最近3か月以内に利用実績がある
- [ ] AIの出力品質向上に寄与している
- [ ] 削除時の影響範囲を把握している

#### プラグイン・MCP

- [ ] なぜ導入したか説明できる
- [ ] 管理者が明確になっている
- [ ] 利用権限が適切に設定されている
- [ ] 定期的にバージョン確認を行っている
- [ ] 代替手段の有無を把握している
- [ ] 障害発生時に無効化する手順がある

#### RAG・ナレッジ

- [ ] 情報源が明確になっている
- [ ] 古い情報が混在していない
- [ ] 機密情報が含まれていない
- [ ] 更新責任者が定義されている
- [ ] AIが参照すべき情報と不要な情報が整理されている

#### ガードレール

- [ ] AIが変更してよい範囲が定義されている
- [ ] AIが変更してはいけない範囲が定義されている
- [ ] 人間レビューが必要な条件が定義されている
- [ ] 自動停止条件が定義されている
- [ ] 監査ログを取得できる

#### 障害対応

- [ ] 最小構成へ戻す手順が存在する
- [ ] 原因切り分け手順が存在する
- [ ] ロールバック手順が存在する
- [ ] 緊急停止方法を把握している
- [ ] 定期的に訓練・見直しを実施している

2-4.コミュニケーションコストを減らすために報告のスタイルをスキル化・ルール化して対応させる

AIを活用していると、モデルの性能やプロンプトばかりに注目しがちです。

しかし実務では、AIが何を報告し、どのような形式で共有するのかを定義する方が重要な場合があります。

例えば、人間同士の開発でも

報告内容が毎回異なる
進捗状況の粒度が揃っていない
完了と未完了の基準が曖昧

という状態では、チーム全体の生産性が低下します。

AIも同様です。

毎回異なる形式で結果を報告していると、

何を実施したのか
何が終わったのか
どこで問題が発生したのか
次に何をするべきなのか

を把握するために余計な確認作業が発生します。

これは、人間の認知負荷を増加させる大きな要因になります。そのため、AIとのやり取りにおいても報告フォーマットを標準化することが重要です。

報告フォーマット例

# 目的・結論
- 何を達成したか
- できなかったなら進捗率何%で何がネックなのか
- 何を達成しようとしているか

# 実施内容
- 今回変更した内容

# 確認結果
- テスト結果や検証結果

# 懸念事項
- 未解決の問題

# 次のアクション
- 次回実施予定

また、スキルやテンプレートとして事前に登録しておけば、毎回細かな指示を繰り返す必要もありません。

必要であれば『現時点のAIと齟齬がないか』を直接確認させてルールやスキルに組み込むことも視野に入れていいと思います。これはAIのためというより、人間のための仕組みです。

前編で紹介したインシデントについても、もし途中経過や判断理由の仕組みが確立されていれば、より早い段階で異常に気付けた可能性があります。

AIを疑うのではなく、AIを守る。それは結果的に、人間自身の仕事を守ることにもつながるのではないでしょうか。

最後に：前後編のまとめ

前編では、AIエージェントが引き起こした三つのインシデントを紹介しました。

そして後編では、それらの多くがAIそのものではなく、

不十分なガードレール
プラグインの競合
業務ルールの未整備
ドメイン知識不足

によって発生していたことを説明しました。

AIは強力な実現手段です。しかし、実現手段である以上、適切な設計・監視・検証がなければ期待した成果にはたどり着けません。

人間が責任を持って

何を任せるのか
何を任せないのか
どこで止めるのか

を設計する必要があります。

AI時代に求められるのは、AIを使う能力だけではありません。

AIが安全に成果を出せる環境を設計する能力こそが、これからの実務で重要になると私は考えています。

採用情報

MSOL Digitalでは、ミッション・ビジョンの実現に向けて、新たな仲間を募集しています。

少しでもご興味をお持ちいただけましたら、ぜひエントリーをご検討ください。

採用エントリーページ

また、すぐに転職をお考えでない場合でも、カジュアル面談からのスタートも大歓迎です。まずはお気軽にお話しできますと幸いです！

カジュアル面談・お問い合わせ