AIコーディングツールを使い始めると、開発の進み方が変わります。以前なら自分で調べ、自分で書き、自分で修正していた作業を、Codex、GitHub Copilot、Claude Code、Cursorなどにかなり任せられるようになりました。バグ修正、テスト追加、ドキュメント更新、リファクタリングの下調べなどは、AIエージェントと相性がよい作業です。
一方で、便利になるほど後から困ることもあります。「この変更は誰が、どんな意図で入れたのか」「AIにどこまで任せたのか」「人間は何を確認したのか」が残っていないと、数週間後の保守やレビューでつまずきます。AIが書いたコードそのものより、AIを使った作業の痕跡が見えないことが問題になる場面が増えていくはずです。
この記事では、AIが書いたコードをチームや未来の自分が見失わないために、コミット、PR、作業メモへ何を残すとよいかを整理します。大企業向けの重い監査ログではなく、フリーランスSEや小規模チームが今日から使える「軽い利用ログ設計」です。
結論：AI利用は隠すより、作業単位で軽く残す
結論から言うと、AI利用は細かく監視するより、作業単位で軽く残すのが現実的です。すべての補完候補やチャット履歴を保存しようとすると重くなります。逆に、何も残さないと後で説明できません。
ちょうどよい落としどころは、次の5点です。
- どの作業でAIを使ったか
- どのツールを使ったか
- AIに何を依頼したか
- 人間が何を確認したか
- どの検証を通したか
この5点が残っていれば、後から見たときに「AI任せで入った怪しい変更」ではなく、「AIを使って作業したが、人間がここを確認した変更」として扱えます。これは心理的にも大きいです。
AI利用はPRだけでは見えない
GitHub Copilot cloud agentの公式ドキュメントでは、エージェントがリポジトリを調査し、実装計画を作り、ブランチ上で変更し、PR作成前に人間がレビューや反復をできる流れが説明されています。このようなクラウドエージェントでは、作業がGitHub上に残りやすく、PRやログを見ればある程度追跡できます。
しかし、AIコーディングツールの使われ方はそれだけではありません。エディタ内の補完、チャットでの相談、CLIでの一括修正、ローカルでのリファクタリング、ドキュメント生成など、AIはさまざまな場所で使われます。PRを作る前に人間がローカルで取り込んだ変更は、履歴上は普通の人間コミットに見えることもあります。
2026年6月に公開された「Detecting AI Coding Agents in Open Source」という研究では、AIコーディングエージェントの利用痕跡は、botアカウントだけを見ても十分には把握できないとされています。コミットメッセージ、設定ファイル、作者情報、bot署名など複数の手がかりを組み合わせる必要があり、PR上に出てくる利用とローカル・エディタ上の利用はかなり違う見え方をします。
この話は、企業の大規模分析だけではなく、小さなチームにも関係します。「AIが使われたかどうか」を後から完全に推定するのは難しい。だからこそ、使った本人が軽く記録する運用を作ったほうが早いです。
残すべき情報1：使ったツールと作業範囲
まず残したいのは、使ったツールと作業範囲です。ここで細かなモデル名や全プロンプトまで残す必要はありません。最低限、次のような粒度で十分です。
- Codexで既存コードを調査した
- Claude Codeでテスト追加案を出した
- GitHub Copilot cloud agentにIssueを割り当てた
- Cursorでリファクタリング候補を相談した
- ChatGPTでPR説明文を整理した
大事なのは、「AIがどこに関与したのか」を読み手が判断できることです。たとえば、PR本文に次のような一文があるだけでも、レビューの姿勢が変わります。
AI利用メモ：
- Codexで既存実装の調査と修正案の洗い出しを実施
- 実装判断と最終差分は人間が確認
- テストは npm test と手動表示確認を実施これなら、AI利用を過度に重く扱わず、レビューに必要な情報だけ残せます。
残すべき情報2：依頼内容の要約
次に残したいのは、AIへの依頼内容です。全文を保存する必要はありません。むしろ、長いチャット履歴をPRに貼ると読みにくくなります。必要なのは、作業の意図が分かる要約です。
例としては、次のような書き方です。
AIへの依頼：
- ログイン後の設定画面で、未保存変更があるときに警告を出す方法を調査
- 既存のフォーム構造を崩さず、最小差分で実装する方針を依頼
- デザイン変更や新しい状態管理ライブラリの追加はしない条件を指定このメモがあると、レビューする人は「AIに何を任せたのか」「やらないことを指定していたのか」を把握できます。AIが勝手に大きく変更したのか、人間が制約を与えたのかで、レビューの見方は変わります。
残すべき情報3：人間が確認した点
AI利用ログで一番大事なのは、使ったAIの名前ではなく、人間が何を確認したかです。AIが作った差分でも、人間が仕様、テスト、セキュリティ、既存設計との整合を確認していれば、チームとして扱いやすくなります。
確認ポイントは、作業の種類によって変わります。
- バグ修正：再現条件、原因、修正後の確認手順
- テスト追加：何を保証するテストか、既存テストとの重複がないか
- リファクタリング：外部仕様が変わっていないか、差分が広がりすぎていないか
- ドキュメント更新：実装と説明がズレていないか
- セキュリティ修正：秘密情報、入力検証、権限、ログの扱い
PR本文には、次のような形で残すと扱いやすいです。
人間確認：
- 変更対象は設定画面の未保存警告に限定
- 既存の保存処理には手を入れていないことを確認
- npm test が通ることを確認
- ブラウザで保存前・保存後・キャンセル時の挙動を確認この程度なら、日々の開発でも負担になりにくいです。
コミットメッセージにAI利用を書くべきか
コミットメッセージにAI利用を書くかどうかは、チーム方針によります。必ず書くべきと断定はしません。顧客案件、OSS、社内規定、契約によって考え方が違うからです。
ただ、小規模チームや個人開発で後から見返す目的なら、コミットメッセージに軽く残すのは有効です。
fix: 設定画面の未保存警告を追加
- Codexで既存フォーム構造を調査
- 実装と検証は人間が確認
- npm test 実行済みただし、すべてのコミットに「AI使用」と書くとノイズになる場合もあります。その場合は、PR本文や作業メモに集約するほうが読みやすいです。
PR本文テンプレート
AI利用を残すなら、PR本文にテンプレートを置くのが一番始めやすいです。たとえば、次のような形です。
## 変更内容
## 背景
## AI利用メモ
- 使用ツール：
- 依頼内容：
- AIが提案した主な変更：
- 人間が採用しなかった提案：
## 人間確認
- 仕様確認：
- セキュリティ確認：
- 既存設計との整合：
## 検証
- 実行したテスト：
- 手動確認：
- 未確認事項：このテンプレートのよいところは、AI利用だけを特別扱いしすぎないことです。背景、変更内容、検証と同じ場所に置くので、普通の開発フローに自然に混ぜられます。
また、「AIが提案したが採用しなかった変更」を残す欄は意外と役に立ちます。AIは便利ですが、不要な抽象化、大きすぎるリファクタリング、新しい依存ライブラリを提案することがあります。それを採用しなかった理由が残っていると、レビューする人も安心できます。
作業メモテンプレート
PRを作らない作業もあります。個人ブログの運用、WordPress下書きの修正、ローカルスクリプトの整理、調査メモ作成などです。この場合は、作業メモにAI利用を残します。
半農エンジニアラボでは、調査メモの先頭に Codex Context Capsule を置き、結論、優先案、重複回避、主要URL、相談事項を短く残す運用にしています。これを開発作業に応用するなら、次のような形が使えます。
## AI作業メモ
- 目的：
- 使用ツール：
- AIに依頼したこと：
- 人間が判断したこと：
- 検証結果：
- 次回注意すること：この程度なら、毎回長い記録を書かなくても済みます。将来の自分が見返したとき、「なぜこの変更をしたのか」が分かれば十分です。
AI利用ログを重くしすぎない
AI利用ログは、重くしすぎると続きません。毎回スクリーンショットを保存する、すべてのプロンプトを保管する、補完候補まで記録する、といった運用は、よほど必要がない限り個人開発には向きません。
おすすめは、作業のリスクで記録量を変えることです。
- 低リスク：文言修正、README更新、軽いメモ整理は簡単な一行でよい
- 中リスク：コード変更、テスト追加、設定変更はPR本文にAI利用メモを残す
- 高リスク：認証、決済、個人情報、公開設定、削除処理はAI利用メモに加えて人間レビューを必須にする
AI利用をすべて同じ重さで扱う必要はありません。重要なのは、後から困る作業ほど記録を厚くすることです。
顧客案件では契約とルールを確認する
フリーランスSEとしてAIツールを使う場合、顧客コードや業務データの扱いは慎重に考える必要があります。ここは一般論で断定できません。契約、社内規定、利用するAIツールのデータ取り扱い、持ち出し禁止情報の範囲によって変わります。
そのため、記事としては「AI利用を必ず開示すべき」「このツールなら問題ない」とは書かないほうが安全です。代わりに、次のような確認項目を持つのが現実的です。
- 顧客コードを外部AIに入力してよい契約か
- 機密情報、個人情報、認証情報を含めていないか
- AI利用の可否が社内ルールで決まっていないか
- AI利用を成果物や作業報告にどう書くか
- 不明な場合に誰へ確認するか
AI利用ログは、こうした確認にも役立ちます。何を入力し、何を出力し、どこを人間が確認したかが残っていれば、後から説明しやすくなります。
チームで始めるなら最初は3項目だけでよい
小さなチームでいきなり厳密なルールを作ると、現場が止まります。最初は、次の3項目だけでも十分です。
- AIを使った作業はPR本文に一行残す
- 認証・権限・削除・公開設定に関わる変更は人間レビュー必須にする
- AIが提案した不要な大規模変更は採用しない理由を書く
これだけでも、レビュー時の不安はかなり減ります。AI利用を禁止するのではなく、見える状態にする。これが実務では続けやすいと思います。
半農エンジニアラボでの応用
このブログ運用でも、AI利用ログの考え方はすでに役立っています。調査メモでは、どのテーマを調べたか、どのURLを見たか、どの案を優先したか、相談事項は何かを残しています。WordPress下書き保存では、投稿ステータスが下書きであること、カテゴリ、タグ、下書きURL、確認点を報告します。
これを開発作業にも広げるなら、Codexにスクリプト修正や記事生成補助を頼んだとき、次の情報を残すとよさそうです。
- 依頼した作業の目的
- 触ったファイル
- 実行した確認コマンド
- WordPressやSNSなど外部公開に関わる操作をしていないこと
- 人間が確認すべき点
ブログ運用は、コード開発ほど厳密なレビューがない場合もあります。しかし、公開や投稿に関わる操作があるため、むしろ記録が大事です。AI利用ログは、技術チームだけでなく、個人ブログ運用にも効く考え方です。
まとめ
AIコーディングツールは、開発を速くしてくれます。けれど、変更の背景や確認内容が残っていないと、未来の自分やチームが困ります。
残すべきなのは、AIとの会話すべてではありません。どの作業でAIを使ったか、何を依頼したか、人間が何を確認したか、どの検証を通したか。この程度の軽い記録で十分です。
AI利用を見える化すると、レビューがしやすくなり、顧客やチームにも説明しやすくなります。AIを使ったかどうかを隠すより、どう使い、どこを人間が判断したかを残す。これからのSE仕事術では、その小さなメモが保守性を支えると思います。
