「AIが書いたコード、
誰が責任を持つのか」
──全作業を証跡化する開発運用

なぜ今「開発の証跡」が問われるのか

2025〜2026 年、ソフトウェア開発の現場は「人がコードを書く」から「AI に書かせて人がレビューする」へと急速に移りました。Claude Code をはじめとする AI エージェントは、調査・実装・テスト・デプロイまでを一気に進めてくれます。生産性は跳ね上がりました。しかし、その裏返しで経営者・発注者からこんな声が出てきます。

• 「その変更、誰が・いつ・なぜ入れたのか説明できるか？」
• 「AI が勝手に書いたコードを、本当に人がレビューしたのか？」
• 「障害が起きたとき、原因と対応の経緯を遡れるか？」
• 「担当者が辞めたら、その案件はブラックボックスにならないか？」

これらはすべて「トレーサビリティ（追跡可能性）」の問いです。スピードを上げれば上げるほど、「速いが説明できない開発」はリスクになります。とくに受託開発では、納品物の品質を顧客に説明する責任から逃れられません。

証跡の 4 層モデル：Redmine／GitHub／Obsidian／Growi

テクノスフィアでは、1 つの作業を性質の異なる 4 つの層に分けて記録しています。それぞれが「異なる問い」に答える証跡です。

層をまたいで「1 本の線」でつなぐ

4 層がバラバラに存在しても証跡にはなりません。鍵は Redmine チケット番号です。弊社では「すべてのコミット・PR・ブランチにチケット番号を含める」を社内規約にしています。

# ブランチ名にチケット番号
feature/220-blog-audit-trail

# コミットメッセージに refs #220
git commit -m "feat: refs #220 証跡管理の技術記事を追加"

# PR タイトルにも refs #220
gh pr create --title "refs #220 証跡管理の技術ブログを追加"

Redmine は GitHub と双方向連携しているため、refs #220 を含むコミットや PR は自動的に Redmine チケットへ紐づきます。これにより「チケット → コミット → PR → 作業ログ」が 1 本の線でつながり、どこからでも全体を辿れる状態になります。

Claude Code が残す「実行の証跡」

4 層モデルに、もう 1 つ現代的な層が加わります。AI エージェント自身の実行ログです。テクノスフィアでは Claude Code を実装の主戦力に据えていますが、その作業は「見えないブラックボックス」ではありません。

• セッションの全やり取りが記録される：どんな指示に対し、どのファイルをどう編集し、どんなコマンドを実行したかが時系列で残る
• 作業ログへ自動で要約・追記：セッションの節目ごとに Obsidian の日次作業ログへ「何をやったか」を自動追記（人手の記録漏れがゼロ）
• Redmine・Git と連動：起票・ブランチ・コミット・PR・チケット更新までを一気通貫で実行し、すべてに番号を通す

つまり Claude Code は「実装する道具」であると同時に「証跡を生成する装置」でもあります。人間は最終レビューと承認（マージ）に集中し、記録は AI が漏れなく残す。この分担が、速度と説明責任を同時に成立させる肝です。

実例：1 週間気づかれなかった障害を証跡から追う

抽象論だけでは伝わりません。この記事を書いた当日（2026年6月13日）に実際に起きた出来事を、証跡の力が分かる事例として紹介します。

発覚：別作業の検証中に「フォームが壊れている」

Google 広告まわりの計測を改善する作業の途中で、自社サイトのお問い合わせフォームが途中までしか表示されていないことに気づきました。送信ボタンが出ない＝問い合わせがまったく送れない状態です。

追跡：いつ・どの変更で壊れたか

ここで証跡が効きます。当該ファイルの変更履歴（Git）を遡ると、原因は 6 日前のあるコミットでした。サニタイズ関数の定義位置が原因で、特定の表示経路だけ PHP の致命的エラーになり、本番ではエラー非表示設定のため「フォームが短く見えるだけ」で誰も異常に気づけなかったのです。

原因コミット（6日前）：機能追加時に
  関数 h() を「送信時の処理ブロックの中」で定義
  → 表示だけの経路（GET）では h() が未定義
  → Fatal error で描画が途中停止
  → display_errors off の本番では“短いページ”にしか見えない

変更履歴がなければ「いつからか分からない」で延々と切り分ける場面です。証跡があれば、壊れた瞬間とその理由をピンポイントで特定できます。

修正・検証・記録まで一気通貫

原因が分かれば、あとは 4 層の証跡を通しながら直すだけです。

1. Redmine: 緊急バグとして起票（影響と原因を明記）
2. GitHub: 修正ブランチ → コミット（refs で番号を通す）
3. 検証   : Docker でビルトインサーバを立て、描画が
            送信ボタンまで復活することを確認
4. PR     : 人間がレビューしてマージ → 本番自動デプロイ
5. 確認   : 本番URLを取得し、フォームが復旧したことを実測
6. Redmine: 検証結果を添えてクローズ、作業時間も記録
7. Obsidian: 一連の経緯を日次作業ログへ自動追記

この障害が「6 日前から問い合わせが送れていなかった」という重い事実も、原因・対応・再発防止の教訓もすべて記録に残りました。後日「あの一週間、なぜ問い合わせがゼロだったのか」を問われても、1 本の線で説明できます。これこそが証跡を残す運用の真価です。

証跡がビジネスにもたらす 4 つの価値

証跡管理は「真面目だが地味な事務作業」ではありません。実際のビジネス価値に直結します。

① 品質保証：障害に強くなる

先の事例のとおり、「いつ・どの変更で・なぜ壊れたか」を遡れることは、復旧速度と再発防止を直接押し上げます。原因究明に費やす時間が桁で変わります。

② 監査対応：AI 活用の説明責任を果たす

「AI が書いたコードを人が承認したか」を、PR の承認者・マージ時刻という消えない記録で示せます。情報システム部門やセキュリティ監査の要求にも、証跡で応えられます。

③ 引き継ぎ：属人化を防ぐ

担当者が変わっても、チケットと作業ログを辿れば「現状」と「なぜそうなっているか」が分かります。プロジェクトページの自動更新ゾーンを見るだけで状況を把握できる状態を保っています。

④ 顧客説明：報告に厚みが出る

作業ログを集約すれば、月次報告や障害報告を事実ベースで即座に組み立てられます。「やったはず」ではなく「この記録のとおりやりました」と言える強さは、受託開発の信頼に直結します。

証跡を回す 3 つの原則とよくある失敗

3 ヶ月以上この運用を回してきて見えた、続けられる証跡管理の原則です。

原則① チケット番号をすべてに通す

ブランチ・コミット・PR・作業ログに必ず Redmine 番号を入れる。これが 4 層をつなぐ関節です。番号のない作業は証跡から孤立します。「チケットがなければ着手しない」を徹底するのが近道です。

原則② 記録は AI に任せ、人は承認に集中する

記録を人手に頼ると、忙しい日ほど抜けます。記録の生成は AI に自動化させ、人間は「マージ」「本番反映」「顧客への約束」といった判断と承認にリソースを割く。役割分担で証跡が安定します。

原則③ 自動更新と手書きを「壊さず共存」させる

AI による自動更新が人の手書きメモを上書きすると、誰も記録を信じなくなります。弊社では更新領域をマーカーで囲い、その内側だけ AI が更新する方式を採り、自動と手動を安全に共存させています。

まとめ

テクノスフィアは、AI エージェント（Claude Code / OpenClaw 等）を Redmine・GitHub・Obsidian・Growi・社内ファイルサーバと連携させ、作業の起票から記録・ナレッジ化までを自動で証跡化する開発体制を自社で実践しています。「AI を開発に使いたいが品質保証が不安」「障害や監査に強い開発プロセスにしたい」といったご相談を歓迎します。