8月24日、Gleb Tsipurskyが「Responsible AI adoption needs developer workflow design」と題した記事を公開した。AIポリシーをドキュメントではなくエンジニアリングワークフローとして設計することが、責任あるAI活用の核心であるという主張だ。「シャドーAI（野良AI）」をコンプライアンス問題として扱う組織は、対処の矢印がそもそも逆を向いている——というのが記事の根本的な診断である。

「シャドーAI」はポリシー違反ではなく、設計の失敗だ

組織がAI利用ポリシーを作成し、「あとは社員が読んで従うだろう」と想定した瞬間に、シャドーAI（野良AI）の温床が生まれる。

Stack Overflowの開発者調査（2025年版）によれば、回答者の84%がAIツールを使用または使用予定と答えている。一方で、AIの精度を「信頼する」開発者より「不信任する」開発者の方が多く、最大の不満は「一見正しそうだが追加デバッグが必要なアウトプット」だ。

Microsoftの調査（Work Trend Index）では、承認されていない個人ツールを業務に持ち込む「BYOA（Bring Your Own AI）」が広まっており、多くのユーザーが重要業務にAIを使っていることを認めたがらないという実態も明らかになっている。

重要なのは、こうした行動が必ずしも「不注意」を意味しないという点だ。公式ルートがそもそも使い物にならないとき、エンジニアはより速い非公式ルートを自分で作る——それだけの話だ。Tsipurskyはこれを「コンプライアンス問題」ではなく「設計の失敗」として診断する。対処法も変わる。「なぜ外部ツールを使ったのか」を追及するのではなく、「どのタスクが開発者を外部ツールへ向かわせているのか」を問うべきだ。

ポリシーをエンジニアリングインターフェースにする

ポリシーは「意図」を定義するが、現場で必要なのは「普段の仕事の中で即座に判断できる運用レベルの答え」だ。記事ではその具体例として、以下のような問いを列挙している。

• 各ツールにどのデータを入力してよいか
• AIが生成したコードにはどのレベルのレビューが必要か
• 有害・不安全・信頼性の低いアウトプットを見つけたら何をすべきか
• いつ実験がプロダクションシステムとみなされるか

Stack Overflowの技術採用調査では、開発者がツールを拒否する最大の理由がセキュリティとプライバシーへの懸念であることが示されている。つまり明確な運用ルールは、採用を阻害するどころかむしろ採用を後押しする。

NISTのAIリスク管理フレームワークが示す「Govern・Map・Measure・Manage」の4機能も、これが継続的な実務であることを示している。委員会にミーティングを申請しなくても答えが出るくらいの解像度で、ポリシーを落とし込む必要がある。

ガードレールはワークフローの中に置く

ラーニングポータルに保存されたポリシー文書は、IDEに組み込まれたAIアシスタントと競合してまず負ける。

リポジトリ、プルリクエスト、ビルドパイプライン、デプロイワークフロー——コントロールは作業が発生する場所に置くべきだ。具体的には、承認済みモデル設定のバージョン管理、ロールによるアクセス制限、プロンプト・アウトプットへのシークレットスキャン、高リスク用途のログ保存、そしてAI生成変更のマージ前テスト要件などが挙げられる。

GitHubのAI生成コードレビューガイダンスは、機能確認・コンテキスト検証・依存関係レビュー・共同レビュー・適切な自動化を推奨しており、「AIアウトプットをレビューせよ」という抽象的な指示を、繰り返し実行可能なエンジニアリングプロセスへと変換している。

またOWASPの生成AIリスクTop10が示すように、コード説明に使うAIと本番システムへの書き込み権限を持つエージェントでは、リスクプロファイルがまったく異なる。同じ承認負荷をかけることは、安全性を高めずに遅延だけを生む。

「誰が責任者か」を道具が動く前に決める

AIを「コラボレーター」「エージェント」と呼ぶ語彙は便利だが、ソフトウェアが組織的な説明責任を引き受けることはできない。記事が強調するのは、この当たり前の事実が、AIの擬人化表現の普及とともに現場で見落とされ始めているという点だ。

記事が提示する責任分担は明快だ。プロダクトリーダーはビジネス判断、エンジニアリングリーダーは実装品質、セキュリティ・プライバシー担当者はコントロールの定義、開発者は自分が提出するコード、レビュアーは承認判断、オペレーターは本番監視と障害対応——を、それぞれ所有する。

全員がAIシステムに触れているのに誰もその結果を所有しない、という「よくある失敗パターン」を防ぐための分業だ。この責任マップをワークフロー設計の段階で明文化しておくことが、インシデント発生後の「誰のせいか」論争を未然に防ぐ。

測定するのはツール使用量ではなく、チームアウトカム

ライセンス数、送信プロンプト数、週次アクティブユーザー数はAIの「活動量」を示すが、エンジニアリング上の価値や責任ある使用についてはほとんど何も語らない。

2024年のDORA調査では、AI活用度の高さがドキュメント品質・コード品質・レビュー速度の改善と相関する一方、ソフトウェアデリバリーパフォーマンスへの負の影響も報告されている。Stack Overflowの調査でも、AIエージェントは個人生産性には寄与するがチームコラボレーションには寄与しないという結果が出ている。

あるエンジニアがローカルタスクを速く終わらせる間に、検証・統合・メンテナンスの作業が同僚に移転している可能性がある。責任ある測定は、最初の見かけ上の成果で止まらず、チーム全体を通じて作業を追いかける。

安全なパスを最速のパスにする

記事の結論はシンプルだ。責任あるAI活用が成立するかどうかは、「ポリシーがあるかどうか」よりも「日々の仕事の仕組みが責任ある行動を現実的に可能にしているかどうか」にかかっている。

開発者が判断・説明責任・エンジニアリング規律を手放さずに速く動けるよう、承認済みパスを設計する——それがリーダーに求められることだ。

詳細はResponsible AI adoption needs developer workflow designを参照していただきたい。