こんにちは。ACS事業部の越川です。
先日、ITmediaで「AIの出力をそのまま使う」リスクについて7項目を整理した記事が公開されました。品質、ライセンス、セキュリティ、エージェントの権限管理など、指摘されているリスクはいずれも的を射ています。
ただ、読み終えて感じたのは「ではどうすればいいのか」が見えないことでした。問題提起は大事ですが、現場のエンジニアが欲しいのは「怖いのはわかった。で、どうする？」の部分です。
当社ではGemini Proを全社導入しており、それ以外も必要な部署が申請してツールを利用できる制度があります。私たちの事業部でもMicrosoftパートナー企業として、現在 GitHub Copilot と Claude Code を導入・活用しています。AIを日常的に使っているからこそ、リスクに対して仕組みで対処してきました。この記事では、その実践を共有します。
怖がるのはエンジニアとして正しい
最初に断っておきたいのは、AIのリスクを怖いと感じるのはエンジニアとして正常な反応だということです。
「AIの出力をそのまま使って大丈夫か？」「エージェントが勝手に変なことをしないか？」という不安は、システムの信頼性を気にする職業意識の表れです。その感覚を無視してはいけません。
大事なのは、怖いと感じた内容を「ルール」にし、ルールを「仕組み」にすることです。怖いまま止めるのでも、怖さを無視して突き進むのでもなく、仕組みで安全にする道を選びます。
7つのリスクを3つに整理する
元記事の7つのリスクのうち、エンジニアが現場で対処できるものに絞ると3つになります。
| リスク | 元記事の該当項目 | 内容 |
|---|---|---|
| 品質リスク | AIの出力品質、ライセンス問題 | AIの出力を検証せずにそのまま使ってしまう |
| 権限リスク | エージェントの脆弱性、データアクセス | AIエージェントが想定外の操作をする |
| 統制リスク | IT管理者の認知不足 | 誰がどのAIツールを何の目的で使っているか把握できない |
残りの4項目（学習データの汚染、サイドロードマルウェア等）はプラットフォーム側やセキュリティチームの領域であり、個々のエンジニアが直接対処するものではありません。ここでは、エンジニア自身が仕組みで対処できる3つに絞って話を進めます。
3層の仕組みで防ぐ
私たちのチームでは、以下の3層でリスクに対処しています。
第1層: 確率的レイヤー（CLAUDE.md / Gemini Gem）
Claude Code には CLAUDE.md という仕組みがあります。プロジェクトのルール・コンプライアンス基準・判断軸を1つのファイルに書き、AIが毎回読み込んで合意に沿って動きます。
## コンプライアンス（公開前に必ず確認） - 公開記事では社内の人間は全て「メンバー」と表記する - プロジェクトに関するネタは一切出さない（NDA抵触） - AIが書いた内容であっても、自分で説明できないものは載せない
「確率的」と呼ぶ理由は、AIが100%ルールを守る保証がないからです。モデルの注意力やコンテキストの長さによって遵守率が変わります。しかし、何も書かなければ0%です。書けば大半の場面で守られます。
第2層: 決定論的レイヤー（Claude Code hooks 8本）
確率的レイヤーだけでは防げないものがあります。そこでClaude Code hooksを使い、ルール違反を決定論的に検出・ブロックします。
以下は私たちが実際に運用している8本のhooksの一部です。
guard-commit.sh — git commit時に機密ファイル（.env、credentials等）のステージングを検出し、ブロックします。
lint-article.sh — 記事の書き込み後に、はてなブログ固有のレンダリング崩れ（太字内のカギ括弧等）やQiita固有の記法ミス（$のエスケープ漏れ）を自動検出します。
grok-article-review.sh — 別のAI（Grok）が読者視点で記事を読み、論理の飛躍や攻撃的な口調を指摘します。書いた本人では気づきにくい問題を、AIで多角的にチェックする仕組みです。
これらは正規表現やシェルスクリプトで動くため、同じ入力に対して必ず同じ結果を返します。AIの注意力に依存しません。
第3層: 人間レイヤー（Slackレビュー / 稟議・法務）
AIのチェックでは防げないものがあります。固有名詞の正確性、組織のコンテキストに依存する判断、NDAへの抵触可能性などです。
これらは社内Slackでの下書き共有とメンバーからのフィードバックで対処しています。AIが書いた文章を人間の目で確認し、最終判断は人間が持ちます。
また、AIツール自体の導入においても、稟議と法務チェックを経て正規に承認されたツールのみを使用しています。社内では別の事業部がClaude Codeを先行利用しており、ACS事業部でも法務確認を経て Claude Code Team Premium を導入しました。「誰かが勝手に使い始めた」ではなく、ガバナンスの下で導入判断をしています。
リスクと仕組みの対応表
| リスク | 第1層（確率的） | 第2層（決定論的） | 第3層（人間） |
|---|---|---|---|
| 品質リスク | CLAUDE.mdで品質基準を定義 | lint-article.shで記法ミスをブロック、grok-article-review.shで論理チェック | Slackレビューで最終判断 |
| 権限リスク | CLAUDE.mdで操作制限を記述 | guard-commit.shで機密ファイル検出 | — |
| 統制リスク | — | — | 稟議・法務チェック、正規導入プロセス |
品質リスクは3層全てでカバーしています。権限リスクは第1層と第2層で対処しています。統制リスクは仕組みではなく組織のプロセスで担保しています。
全てのリスクを1つの層で防ごうとすると無理が生じます。リスクの性質によって適切な層が異なることを認識し、使い分けることが重要です。
怖さを仕組みに変える
元記事の結論は「AI停止ではなくガバナンスの構築が重要」でした。私たちも同意します。
エンジニアが怖いと感じたとき、取れる行動は3つあります。
- 止める — AIの利用をやめる。安全だが、生産性の向上を放棄する
- 無視する — 怖さを感じたまま使い続ける。いつか事故が起きる
- 仕組みにする — 怖さの正体をルールに書き、ルールをスクリプトにし、スクリプトを自動実行する
3番目の道を選んだ結果が、CLAUDE.md + hooks + Slackレビューという3層の仕組みです。
確率的レイヤーと決定論的レイヤーの設計思想については「AIのルール遵守は確率的、hooksは決定論的 — ハーネスの2つのレイヤー」で詳しく書いています。GitHub Copilot と Claude Code の併用については「GitHub Copilotのリクエスト枠を2日で56%消費した失敗から見えた、Claude Codeとの補完関係」をご覧ください。
参考
- 「AIの出力をそのまま使う」「エージェントが勝手に動く」と何がマズいのか？ 陥りがちな7つのリスク（ITmedia AI+、2026/04/10）
- AIのルール遵守は確率的、hooksは決定論的 — ハーネスの2つのレイヤー — 筆者の過去記事
- GitHub Copilotのリクエスト枠を2日で56%消費した失敗から見えた、Claude Codeとの補完関係 — 筆者の過去記事
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
