開発チームにAIを導入するルール｜承認・停止・記録のシート付き

更新日：2026年11月13日

AIでテストを作ることはできても、「誰が差分を承認するのか」「問題が起きたら誰が止めるのか」が決まっていないと、チームで使い続けられません。

最初は作業を1種類に絞り、入力データ・実行権限・レビュー担当・停止条件・再開の承認者を1枚にまとめます。 この記事では、開発者5名が自作コードのテスト追加を2週間試す例と、コピーして使える運用シートを用意しました。

対象はGitとコードレビューの経験があるチーム責任者です。以下は編集部が設計した架空の運用例で、実際の導入実績や安全性の保証ではありません。自社の規程・契約条件に合わせて調整してください。本記事に広告・アフィリエイトリンクはありません。

最初に決めるのは「許可する作業」と「人に戻す作業」

この試行では、社内で利用を承認したAIツールと契約を使います。個人アカウントで代用せず、入力・ログの保存と利用条件を情報システム担当が確認します。

「AIには本番を触らせない」と指示するだけでは、権限を分離したことになりません。アカウント・認証情報・実行環境の側でも、本番へ書き込めない状態を確認します。

ツール設定と運用シートの両方を確認する

Claude Codeを使う場合、公式の権限設定を確認し、利用中のモードと許可範囲を記録します。画面に確認が出るかだけで安全と判断せず、実際に使える権限を点検してください。

公式のセキュリティ案内も、変更・コマンドの確認と権限の点検を案内しています。本記事のシートは、その設定や組織の管理を置き換えません。設定例の実機検証は本記事では行っていないため、万能な設定ファイルとしてコピーするコードは掲載していません。

試行開始前に、管理担当と作業者が次を確認します。

• 使用するツール・版・契約・権限モードを記録したか。
• 試行環境から本番へ書き込む認証情報や経路を除いたか。
• AIが読めるファイルと、接続できる外部ツールを把握したか。
• ログの保存先・閲覧者・保存期間が社内ルールに合うか。

未確認の項目があれば、ダミーの題材でも実行を始めず、担当と確認期限を決めます。

1件の作業は、期待結果を決めてからレビューする

試行題材を「整数のリストを合計する自作関数」とした場合、期待結果はAIに作らせたテストから逆算せず、人が先に決めます。

意図的な誤りを入れるのは、切り離した試行用コピーだけです。既存の共有環境や本番へ不具合を入れないでください。上表は演習手順であり、実行済みの検証結果ではありません。

次のいずれかに該当したら、テストが通っていても採用を保留します。

• 仕様にないファイル・依存関係・権限設定を変えている。
• テストを弱めたり削ったりして合格させている。
• 説明できないコマンドや外部接続を求めている。
• 正常版では通るが、意図的な不具合を検出できない。

テストが誤りを見つけるか、最小の題材で確認する

上の運用を試すため、外部ライブラリもAPIも使わない教材を用意しました。ここで実行確認したのはPythonのテストと意図的な不具合の検出であり、AIによる生成やチーム導入の成果ではありません。 空の練習フォルダーに次の2ファイルをUTF-8で保存します。

sum_tools.py：

def total(values):
    return sum(values)

test_sum_tools.py：

import unittest
from sum_tools import total

class SumTests(unittest.TestCase):
    def test_positive(self):
        self.assertEqual(total([2, 3]), 5)

    def test_empty(self):
        self.assertEqual(total([]), 0)

    def test_negative(self):
        self.assertEqual(total([-2, 3]), 1)

if __name__ == "__main__":
    unittest.main()

練習フォルダーで実行します。

python3 -m unittest -v test_sum_tools

正常版では3件が合格します。次に、練習用のsum_tools.pyだけをエディターで開き、return sum(values)を次へ置き換えます。

    return sum(value for value in values if value > 0)

同じテストコマンドを再実行すると、負数のケースが失敗し、実際の3と期待する1の不一致を検出します。通常入力と空入力だけのテストなら、この誤りを見逃します。テスト件数が多いことと、必要な仕様を検証できることは別です。

最後に元のreturn sum(values)へ戻し、3件が再び合格することを確認してください。編集時の実行では正常版0、不具合版1、復元版0という終了コードを確認しました。不具合版の終了コード1は、この演習では期待する結果です。

レビュー記録には「正常版3件合格／負数の誤りを1件検出／復元後3件合格」を残します。これで確認できるのは、この1種類の誤りを検出できることまでです。型違い、大きな入力、実際の業務仕様まで保証するものではありません。

AIへテスト追加を依頼するときも、仕様と期待値を先に渡し、採用前に人が同じ確認を行います。作業者が実行しても、レビュー担当が記録と差分を説明できなければ承認は待ちます。

問題が起きたときの停止・切り戻し・再開

「止めたら誰に相談するか」まで決めておくと、作業者が一人で判断を抱えずに済みます。以下はこの試行の運用案です。

切り戻しでは、対象コミットと他の人の変更を確認し、チームの既存手順で戻します。共有ブランチを一律に巻き戻す操作は避けます。ログや差分を削除してから報告するのではなく、機密情報を一般チャットへ貼らずに、社内の指定場所へ保全してください。

コピーして使う運用シート

以下を社内文書へ貼り、空欄を埋めます。役職名だけでなく、実際に連絡できる担当者を指定します。

AI利用の試行シート
目的・許可する作業：
対象チーム・人数：
開始日／中間確認日／終了日：
ツール名・版・契約・権限モード：
入力可のデータ／入力不可のデータ：
作業環境・ブランチ／本番権限の分離方法：
許可する外部接続・追加ツール：
作業者／レビュー担当／不在時の代替担当：
人が承認する操作：
必須テスト・採用を保留する条件：
停止条件／最初の連絡先：
切り戻し担当・対象の確認方法：
再開に必要な確認／再開承認者：
記録場所・閲覧者・保存期間：
最終日の判断と次の確認日：

1件ごとの記録も、同じ場所に残します。認証情報や実際の機密データは記録本文へ複製しません。

作業日・担当／対象コミット：
題材・期待結果／使ったツール・版：
AIへ渡した情報の分類・ファイル：
指示／変更差分／実行コマンド・結果の保存先：
準備・生成・確認・修正の時間：
見落とした不具合／停止・切り戻しの有無：
レビュー指摘・修正結果：
採用・保留・不採用／判断者・理由：

2週間後は、継続・条件変更・中止を選ぶ

これは全社導入の合否試験ではなく、次に何を直すかを決める小さな試行です。以下の基準は編集部の例であり、件数や期間は自社の作業量に合わせて開始前に決めます。

担当者・停止手順・記録場所を説明でき、1件を最初から承認まで追えるなら、次は時間・品質・利用率の測定シートで試行結果を整理できます。

自社だけでレビュー基準や演習を設計しづらい場合は、開発チーム向けAI研修の選び方へ進み、「自作コードでの演習、全員への講評、停止・切り戻しの練習に対応できるか」を相談条件にしてください。

出典・このシートの範囲

公式情報確認日：2026年11月13日（権限・セキュリティ資料を再確認）。

• Claude Code：権限設定：利用中の権限設定を確認するための資料。
• Claude Code：セキュリティ：変更・コマンド確認、権限点検の参考。

2026年11月13日、Python 3.9.7 / macOSで、追加した合計関数の正常・不具合・復元テストをローカル実行しました。担当分担、2週間の期間、題材、表、シート、採否基準は編集部の提案です。製品の設定・事故対応を実機検証した記事ではなく、特定の研修会社のサービス条件や受講効果を評価するものでもありません。