# 「AIが書いたコード、誰が責任を持つのか」｜全作業を証跡化する開発運用（Redmine×Growi×Obsidian×Claude Code）｜株式会社テクノスフィア

> 生成AIにコードを書かせる時代の品質と説明責任をどう担保するか。テクノスフィアが Redmine・Growi・Obsidian・Claude Code で全作業を証跡（監査トレース）として残す運用を、実際のフォーム障害を追跡・修正した事例とともに公開します。

URL: https://technosphere.co.jp/blog/ai-development-audit-trail

** 目次
1. なぜ今「開発の証跡」が問われるのか
2. 証跡の 4 層モデル：Redmine／GitHub／Obsidian／Growi
3. Claude Code が残す「実行の証跡」
4. 実例：1 週間気づかれなかった障害を証跡から追う
5. 証跡がビジネスにもたらす 4 つの価値
6. 証跡を回す 3 つの原則とよくある失敗
7. まとめ
    ** 本記事のスコープ

本記事は「**記録をどう自動化するか**」の続編にあたる、「**記録を証跡として、品質と説明責任にどうつなげるか**」という運用思想の話です。スキルによる自動化の実装は [Obsidian作業ログ＋Redmine運用を完全自動化した話](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) で、AI基盤の構築は [OpenClaw 入門](https://technosphere.co.jp/blog/openclaw-getting-started) で扱っています。

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

2025〜2026 年、ソフトウェア開発の現場は「**人がコードを書く**」から「**AI に書かせて人がレビューする**」へと急速に移りました。Claude Code をはじめとする AI エージェントは、調査・実装・テスト・デプロイまでを一気に進めてくれます。生産性は跳ね上がりました。しかし、その裏返しで経営者・発注者からこんな声が出てきます。
- 「その変更、**誰が・いつ・なぜ**入れたのか説明できるか？」
- 「AI が勝手に書いたコードを、**本当に人がレビューした**のか？」
- 「障害が起きたとき、**原因と対応の経緯を遡れる**か？」
- 「担当者が辞めたら、その案件は**ブラックボックス**にならないか？」

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

私たちの答えはシンプルです。**AI に任せる範囲を広げるなら、証跡を残す範囲も同じだけ広げる**。AI が書いたかどうかは問題ではありません。「なぜ着手し、何を変え、どう考え、どう検証したか」がすべて記録に残っていれば、AI活用とガバナンスは両立します。むしろ AI は**記録作業そのものを自動化できる**ぶん、人間だけの時代より証跡を厚くできます。

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

テクノスフィアでは、1 つの作業を**性質の異なる 4 つの層**に分けて記録しています。それぞれが「異なる問い」に答える証跡です。  （図: 証跡の4層モデル：Redmine（なぜ）・GitHub（何を）・Obsidian（どう）・Growi（恒久知））
| 層 | ツール | 答える問い | 残るもの |
| **課題** | Redmine | なぜ着手したか / What | チケット、依頼の背景、期日、担当、ステータス遷移 |
| **変更** | GitHub | 何を変えたか | コミット差分、PR、レビュー、マージ履歴 |
| **過程** | Obsidian | どう考え何をしたか | 日次作業ログ、調査メモ、判断理由、トラブル対応 |
| **恒久知** | Growi | 次に活かす知識 | 手順書、設計指針、再発防止ナレッジ |

### 層をまたいで「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 本の線でつながり、どこからでも全体を辿れる状態になります。  ** なぜ番号の徹底がここまで効くのか

番号はただの整理タグではなく、**4 つの証跡層を結ぶ関節**です。番号さえ通っていれば、後から「この本番障害はどのチケットの、どのコミットで入ったか」を機械的に逆引きできます。逆に番号が欠けた作業は、どれだけ丁寧にメモしても**「線」から外れた孤立点**になってしまいます。

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

4 層モデルに、もう 1 つ現代的な層が加わります。**AI エージェント自身の実行ログ**です。テクノスフィアでは Claude Code を実装の主戦力に据えていますが、その作業は「見えないブラックボックス」ではありません。
- **セッションの全やり取りが記録される：**どんな指示に対し、どのファイルをどう編集し、どんなコマンドを実行したかが時系列で残る
- **作業ログへ自動で要約・追記：**セッションの節目ごとに Obsidian の日次作業ログへ「何をやったか」を自動追記（人手の記録漏れがゼロ）
- **Redmine・Git と連動：**起票・ブランチ・コミット・PR・チケット更新までを一気通貫で実行し、すべてに番号を通す

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

弊社では、本番反映や破壊的操作・外部公開を伴う作業は**必ず人間の承認**を挟みます。AI は調査・実装・記録・検証までを担い、**マージと本番デプロイの引き金は人が引く**。この境界線そのものも証跡（PR の承認者・マージ時刻）として残ります。

## 実例：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 本の線で説明できます**。これこそが証跡を残す運用の真価です。   ／AI開発の「速さ」と「説明責任」を両立したい方へ＼

### 証跡が残る開発体制を、貴社にも

「AIを開発に使いたいが品質保証が不安」「障害時に経緯を追える体制にしたい」──そんな課題は、ツール連携と運用設計で解決できます。スモールPoCからご相談いただけます。 [AI開発・証跡管理の相談をする](https://technosphere.co.jp/contact?category=ai_solution)

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

証跡管理は「真面目だが地味な事務作業」ではありません。実際のビジネス価値に直結します。  （図: 証跡管理がもたらす品質保証・信頼のイメージ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI による自動更新が人の手書きメモを上書きすると、誰も記録を信じなくなります。弊社では更新領域を**マーカーで囲い、その内側だけ AI が更新**する方式を採り、自動と手動を安全に共存させています。  ** よくある 3 つの失敗
- **記録が目的化する：**証跡は手段。10 分で終わる相談まで起票すると形骸化します。粒度の線引きを決めましょう。
- **ツールが分散して線が切れる：**番号で串刺しにしないと、ツールを増やすほど追跡不能になります。
- **本番だけエラーが見えない：**今回の事例のように、本番のエラー非表示設定は障害を隠します。証跡（変更履歴）と監視で補完が必要です。

## まとめ

###  この記事のまとめ
- AI に任せる範囲を広げるなら、**証跡を残す範囲も同じだけ広げる**。AIか人かは問題ではない
- 証跡は **4 層**：Redmine（なぜ）／GitHub（何を）／Obsidian（どう）／Growi（恒久知）
- **Claude Code は実装と同時に証跡を生成**。人はマージ・本番反映の承認に集中する
- 4 層を結ぶ関節は **チケット番号**。`refs #123` をすべてに通す
- 実例：6 日間気づかれなかったフォーム障害を、変更履歴から**瞬時に特定・修正・検証・記録**できた
- 価値は **品質保証・監査対応・引き継ぎ・顧客説明**の 4 つに直結する

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

### AI 活用と説明責任を両立する開発体制づくり

生成AIを開発に取り入れたい、しかし品質・監査・トレーサビリティが不安──そんな企業の「証跡が残る開発プロセス」設計と、Redmine / GitHub / Obsidian / Growi を AI で連携する仕組みづくりをテクノスフィアが支援します。スモール PoC から全社展開まで。  [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [証跡管理・AI開発を相談](https://technosphere.co.jp/contact?category=ai_solution)     # AI開発 # 証跡管理 # トレーサビリティ # Claude Code # Redmine # Obsidian # 監査証跡 # 開発ガバナンス

##   次に読む｜AI業務自動化シリーズ
-  [自動化の実装 Obsidian作業ログ＋Redmineチケット運用を完全自動化した話 本記事の「記録の自動化」側の実装編](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine)
-  [AI基盤の構築 OpenClaw 入門｜OSSのAIアシスタントを社内 Kubernetes で動かす 自社運用のAIエージェント基盤づくり](https://technosphere.co.jp/blog/openclaw-getting-started)
-  [関連記事 RAGチャットボット社内ヘルプデスク導入事例 社内 DX × AI の代表例](https://technosphere.co.jp/blog/rag-chatbot-helpdesk)
-  [サービス AI ソリューション開発 証跡が残る開発体制づくりのご支援](https://technosphere.co.jp/ai-solution)
    [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)