AIコーディングの社内ルール｜入力データ・権限・レビューの項目例

開発者の手元では、既存コードの調査、テスト作成、差分説明がすぐ便利に見えます。組織として同じ作業を見ると、問いは別の形になります。顧客情報は混ざっていないか。外部通信は許可された範囲か。本番の認証情報に触れていないか。

NIST AI Risk Management Frameworkは、AIリスク管理を任意利用の枠組みとして示し、信頼性への考慮をAIシステムの設計、開発、利用、評価へ組み込む考え方を示しています。NISTはAI RMF 1.0が改訂中であることも明示しています。社内ルールも、利用範囲とツール仕様に合わせて手入れし続ける運用物と見る方が現実に合います。

社内ルールでは、作業の種類、入力データ、権限、レビュー責任、例外処理を同じ文脈で結びます。AI駆動開発として開発プロセスへ組み込むなら、速度より先に、人間が止める場所を決める必要があります。下の5項目がそろうと、レビューで確認できる社内基準になります。

入力データの判断で起きやすい誤解は、秘密情報さえ入れなければよいという整理です。実際には、未公開仕様、脆弱性情報、顧客固有の業務フロー、障害対応手順も外へ出したくない文脈になり得ます。コードだけでなく、プロンプト、添付ファイル、ターミナル出力、ログ、ブラウザで取得した内容も入力です。

Claude Codeのセキュリティ文書は、機密コードを扱う際の実務として、提案変更のレビュー、プロジェクト固有の権限設定、開発コンテナによる追加分離、権限設定の定期監査を挙げています。禁止リストだけでは境界が曖昧になります。どのプロジェクトで、どの隔離環境を使い、どのログを渡してよいかまで決めて初めて判断できます。

分類は「入力可」「条件付き可」「入力不可」の3段階が扱いやすい形です。公開済みAPI仕様や機密を含まない再現コードは入力可に近く、個人情報、認証情報、未公開の顧客資料、攻撃再現に使える詳細な脆弱性情報は入力不可です。条件付き可には、マスキング済みログ、抽象化した障害概要、最小限の再現コードを置きます。境界線を利用条件で書くと、現場は判断を保留せずに確認先へ進めます。

権限設計では、便利さよりも失敗時の到達範囲を先に見ます。誤った指示、読み込ませた外部文書、プロンプトインジェクションの影響で、どのファイル、どのコマンド、どのネットワーク先まで届くのか。そこを曖昧にしたまま導入すると、承認ボタンは形式だけになります。

Claude Codeは、追加操作が必要な場合に明示的な許可を求める権限ベースの構造を説明しています。ファイル編集、テスト実行、コマンド実行は人間の承認対象になり、ネットワーク要求やMCPサーバーにも確認の考え方が及びます。

OpenAIが2026年5月に公開したCodex運用の記事も、組織が統制すべき対象として、アクセスできるもの、人間の承認が必要な場面、接続できるシステム、行動を説明するテレメトリを挙げています。サンドボックス、承認、ネットワークポリシー、ID、ログを一つの権限設計として扱います。

社内規程では、読み取り、編集、テスト実行、外部通信、Git操作、本番アクセスを分け、それぞれに許可条件を置きます。Claude Codeのようなエージェント型ツールでは、IDE連携やMCPサーバーの追加も境界に含めます。到達範囲を基準に書くと、ツールが変わっても同じ基準で見直せます。

生成された差分だけを通常のコードレビューに流すと、なぜその変更になったのかが抜け落ちます。入力に不適切なデータがないか。実行コマンドは妥当か。テスト失敗を見落としていないか。依存関係やライセンスにリスクを持ち込んでいないか。レビュー対象を差分だけに閉じると、AIコーディング特有の失敗を見逃します。ライセンス、NOTICE、配布形態の確認はAI生成コードのライセンス確認へ分けて記録します。

Claude Codeの公式文書は、ユーザーが提案コードとコマンドを安全性の観点で確認する責任を持つと説明しています。OpenAIのCodex運用記事は、ユーザープロンプト、ツール承認判断、実行結果、MCP利用、ネットワーク許可や拒否のイベントをログとして扱えることに触れています。

利用時のレビューは三層に分けると運用しやすくなります。通常のコードレビュー、AIへ渡した入力と実行ログの確認、高リスク領域の追加承認です。決済、認証、権限管理、個人情報処理、セキュリティ修正、インフラ変更は、生成有無にかかわらず慎重に見るべき領域です。記録が残れば、次に権限を緩めるか締めるかを判断できます。

どれだけ丁寧に社内ルールを作っても、例外は出ます。障害調査で詳細ログを読み込ませたい。通常は使わないコマンドを実行したい。外部サービス確認のために通信を許したい。単に上長承認と書くだけでは、判断の質が承認者の経験に寄ります。

例外対応に必要なのは、目的、範囲、期限、承認者、記録、終了後の後始末です。渡すデータは最小化し、完了後に一時ファイル、資格情報、共有リンク、接続設定を戻します。MCPサーバーやプラグインの追加も同じです。信頼できる提供元か、設定をソース管理に含めるか、使わなくなった後に外すかを決めます。

NIST AI RMFは、リスクを特定し、測り、管理する考え方を示しています。繰り返し発生する例外は、ルールが現場に合っていないサインです。一度きりの例外は、承認期限を過ぎたら元に戻す対象です。いつ通常状態へ戻すかを明記した方が、実務上のリスクは小さくなります。

全社へ一斉に広げる前に、対象チーム、リポジトリ、タスクを絞る方が判断材料は集まります。低リスクのテスト追加、リファクタリング補助、ドキュメント更新、既存コードの説明から始めると、入力データ、権限、レビューの抜けを見つけやすくなります。

導入時に生産性向上率のような保証できない数字だけを見ると、ルール改善の材料が薄くなります。AI利用PRのレビュー状況、入力禁止データの混入、承認操作、例外申請、違反是正も確認します。これらは社内ルールを更新するための運用情報です。

外部支援を使う場合も、公式パートナーや認定の有無と、社内ルールを作れる実務能力は分けて見ます。Cotomuの公開範囲はAI駆動開発の研修、導入支援、技術顧問です。公開LP上の料金は研修30万円、導入パッケージ50万円から、技術顧問15万円/月、初回60分相談無料ですが、生産性や品質向上を保証するものではありません。Claude CodeやCodexの公式パートナー、認定事業者と誤認させる表現も避けるべきです。

AIコーディングの社内ルールの目的は、開発者を止めることではありません。入力してよいデータ、AIに与える権限、人間がレビューする対象、例外を戻す手順を一枚でつなぎ、迷いを減らすことです。ツールの安全機能は重要ですが、組織の業務データ、契約、承認責任までは自動で理解してくれません。

承認条件は、「誰が、どの範囲で、何を見て承認するか」まで具体化します。入力データの分類と権限設定に加え、レビュー記録と例外の期限も含めて、組織で扱える開発プロセスにします。