AI × TiDD / 2026.09.05 Redmine 大阪

2026/09/05「Redmine 大阪」でのLT資料です。

AIにすべてを丸投げするのではなく、あえて人間をループの中に残し、
チケット（TiDD）とGitをAIとの「対話の場」「関所」「記録」として活用する
実践的な開発アプローチについてお話ししました。

#TiDD #チケット駆動開発 #AI #GitHub #Redmine #Agile #ソフトウェア開発

Transcript

1. AI × TiDD でソフトウェア開発 2026/09/05 Redmine 大阪 @tokudiro
2. 【導入】 自己紹介 tokudiro • プログラミング歴 30 年以上、組み込みソフトウェア開発 • ソフトウェアハウスや SIer で、客先常駐でいろんな製品開発を経験 • テスト駆動開発の入門本の著者 • 認定スクラムマスター（前職で取得） • 現在は事業会社で人流解析センサの開発に従事 • 趣味は山登り、旅行、カメラ、ドラム 2
3. 【導入】 今日話したいこと AI を使った開発で、なぜ 「チケット駆動開発（TiDD）」 がいいのか。 AI に全部任せる のがトレンドの今、あえて人間をループの中に残します。 チケットと Git を、AI と仲良く働くための「場」 「関所」 「記録」にする——そんな考え方を紹介します。 3
4. 【導入】 AI アジャイルソフトウェア開発宣言 私は、人間と AI が協業するソフトウェア開発を通じて、よりよい開発方法を見つけだそうとしている。 この活動を通して、私は以下の価値に至った。 • プロセスやツール よりも 人間と AI の対話を • 包括的なドキュメント よりも 動くソフトウェアと即座のフィードバックを • 完璧な仕様の追求 よりも ユーザー価値の継続的な提供を • 巨大な計画に従うこと よりも AI を活用した迅速な適応を 価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たち(私と AI)は右記 のことがらにより価値をおく。 （アジャイルソフトウェア開発宣言をベースに再定義） 4
5. 【Why】 きっかけ プロンプトを書くのが面倒だった この開発方法を始めたきっかけは、壮大な設計思想ではありません。 「プロンプトを書くのが面倒だった」 という、ごく個人的な作業上の不満でした。 後述する「AI の暴走を防ぐ」という大義名分は、すべて後付けです。 まずはその泥臭い出発点から話します。 • AI との開発では、要求整理と提案確認のやり取りが常について回る • やり取りを重ねるほど、文章は長くなる • その長文を、ターミナルの小さな画面で読み書きするのは単純につらい 5
6. 【Why】 きっかけ チケットを使ってみた 試しに、要求分析や提案確認の作業を、使っているチケット（GitHub issue）に書き出してみました。 すると——作業の負担が、明確に減りました。 何が改善したのか、3 つの理由（＋おまけ 1 つ） 1. 表示領域と可読性 • ブラウザの広い画面で、Markdown が整形されて表示される 2. 対話ログからの切り出し • 流れて消えるチャットから、その時点の合意事項を独立した参照点として残せる 3. 整理して書くという行為そのもの • 書き起こす作業自体が、頭の中の漠然とした要求を整理する強制力を持つ おまけ. Git リポジトリとの相性の良さ • チケットはコミットや PR と直接紐づき、変更履歴と経緯が同じ場所に残る（後から効いてくる利点） この時点では、単なる「作業が楽になった理由」でしかありませんでした。 6
7. 【Why】 AI の暴走を防ぐ AI の暴走と、プロンプト制御の限界 個人的な作業効率化として始めた「チケットに書く」という習慣。 AI とチケット駆動開発を続けるうちに、これがもっと本質的な問題——AI の暴走——を防いでいたこと に気づきます。 AI の暴走という新たな課題 チャットベースで AI に開発を任せると、【軽度】 その場しのぎのパッチコードの埋め込みから、【中 度】 文脈を読み違えた無関係な箇所の書き換え、【重度】 ソフトウェアアーキテクチャに反するコー ドの混入まで、様々な問題が発生します。 「プロンプトによる制御」の限界と挫折 AI を思い通りに動かすため、プロンプトに大量のルールや制約を書くのは 破綻 します。 どんなに細かく指示しても、長いチャットの会話履歴（文脈）に埋もれると、AI は次第にルールを忘れ、 自己解釈で都合よく歪めてしまいます。 実際、ルールファイルに書き足しても、効果があるかどうかは分かりませんでした。ルールは増える一 方で、ファイルだけがどんどん肥大化していきました。 → 少なくとも私は、プロンプトをこねくり回すアプローチで制御できている実感を持てませんでした ※参考: Anthropic 公式ドキュメント「Best practices for Claude Code」 （“Bloated CLAUDE.md files cause Claude to ignore your actual instructions!”） https://code.claude.com/docs/en/best-practices 7
8. 【Why】 AI の暴走を防ぐ チケットの価値、再解釈 実は、さっき挙げた理由の 1 つ——「対話ログからの切り出し」——が、ここで効いてきます。 流れていく会話履歴の外側にある、 「独立した絶対的な参照点」 が必要でした。その境界線として最 も機能するのが、タスクのスコープを定義した 「チケット（Issue）」 です。 docs/spec.md のような仕様ファイルも会話履歴の外側にはありますが、チケットには open/close の ライフサイクルでスコープに始点と終点がある・1 タスク 1 枚という粒度が強制される・コミットや PR と自動的に相互リンクする という 3 つの性質があり、参照点としてより強く機能します。 ❌ ⭕️ チケットの中身自体も、結局は AI のコンテキストに入ります。違うのは、会話が長くなったら新しい セッションを開いて、チケットだけを読み直せることです。 • • プロンプトだけで制御しようとすること 人間と AI の対話 ＝ チケットを介したやり取り 「プロンプトを書くのが面倒だった」という個人の作業改善は、結果として「プロンプトによる制御」の 構造的な限界を、別の手段で回避していた ことになります。 8
9. 【Why】 AI の暴走を防ぐ 実は、目新しい話ではない チケット駆動開発そのものは、AI 時代に発明されたものではありません。 優秀なエンジニアが以前から当たり前のように実践してきたプラクティスです。 TiDD は、目新しい技術ではなく、いい意味で 枯れた実践 です。 9
10. 【Why】 AI の暴走を防ぐ Vibe coding と Harness／Loop Engineering の組合せはない？ Chat coding／Vibe coding／Agentic engineering を、4 つの Engineering 軸※（Loop・Harness・Context・Prompt）で整理 すると—— Loop Engineering Chat coding Vibe coding Agentic engineering — — 定期的に自動実行 作成役と確認役を分離 — — 承認フローと権限管理 自動チェック+隔離実行 手でコードを貼る ファイルを指定 Obsidian参照 AI用の説明書を常備 検索・要約する仕組み 一発で投げる 役割ごとに指示定型化 専門AIに仕事を分担 起動と反復 Harness Engineering 周辺の足場 Context Engineering 文脈の中身 Prompt Engineering 質問文を練る 指示文 名前も実務もある （AIのメモリ保持） 一般には語られていない Vibe coding のまま、Harness Engineering や Loop Engineering をする手法は、一般的には存在しません。 ※参考: futureagi.com「Prompt, Context, Harness, Loop: The Four Layers of AI Agent Engineering」 10
11. 【Why】 AI の暴走を防ぐ Vibe coding と Harness／Loop Engineering の組合せはある！ 同じマトリクスに、TiDD の実務を重ねると—— Loop Engineering Chat coding Vibe coding Agentic engineering — チケット依頼で エージェント起動 定期的に自動実行 作成役と確認役を分離 — チケットで仕様・ 完了条件・証跡を保持 承認フローと権限管理 自動チェック+隔離実行 手でコードを貼る ファイルを指定 Obsidian参照 AI用の説明書を常備 検索・要約する仕組み 一発で投げる 役割ごとに指示定型化 専門AIに仕事を分担 起動と反復 Harness Engineering 周辺の足場 Context Engineering 文脈の中身 Prompt Engineering 質問文を練る 指示文 名前も実務もある （AIのメモリ保持） 名前は無いが実務がある 一般には語られていない しかし、TiDD を導入すると、Vibe coding のまま Harness Engineering や Loop Engineering が可能になります。ただし仕組み は違います——Agentic engineering が自動化されたインフラ（CI・サンドボックス・スケジューラ）で実現するのに対し、TiDD は人間の規律（チケットを書き、レビューする）で実現します。 自動チェックや自動テストなども、チケットの完了条件に書き、環境が整えば実施されます。 インフラを作り込む手間をかけずに、身軽な Vibe coding のまま、チェック体制を開発プロセスに統合できる——これが、AI × TiDD の価値です。 11
12. 【What】 解決策：AI 開発のパイプライン 思考の制御（TiDD）を、私はこう捉えている プロセスを制御工学に見立てて、AI の思考に 物理的なガードレール を設けます。 🎯 🌍 （※厳密な制御理論の話ではなく、TiDD を運用するための私なりの比喩です） 目標値 （チケット） ② スコープ付与 制御対象 （Gitリポジトリ） 目標を都度見返す 🧠 ① 状態観測（成果物の状況） 制御器 （AI推論エンジン） 実際の差分を直接確認 ④ 逸脱（Reject / 再考） ③ 提示（提案→解決策） 👀 ⑤ 確定（Approve / Merge） 誤差検出・判断 （レビュー） 「現在アクティブな単一のチケット」のみをスコープとして与え、その境界線内で思考させ、人と AI が 相談する場を作ります。 12
13. 【How】 TiDD のダブルダイヤモンド 人間が介在する箇所 このループにおいて、人が介在しシステムにコンテキスト（前提知識や仕様）を注入できる箇所が 「誤 差検出・判断（レビュー）」 の段階です。 AI がいきなり完璧な解決策を出すことはありません。最初は 提案 を出力（③）させ、人間がコンテキ ストを注入して再考させる（④）——このループを何度も回します。 この「ループを回して仕様をすり合わせるプロセス」こそが 壁打ち です。 この流れを検査し、通すか差し戻すかを判断する場所こそが、この対話における 「関所」 です。 13
14. 【How】 TiDD のダブルダイヤモンド ③④のループの中身をズームインすると… この壁打ちの具体的な手順を展開すると、実は 「ダブルダイヤモンド」 です。 💎 1. チケット 境界線設定 2. 議論開始 解決策禁止 3. 原因追及 💎 前半のダイヤモンド(設計) 4. 矛盾排除 矛盾なし 5. 仕様合意 定義完了 後半のダイヤモンド(実装) 6. 実装 差分生成 矛盾あり 7. テスト 検証 Pass 8. 人間の監査 9. 確定 Gitへコミット 10. アセット化 知見化 Fail 10 ステップ 1. チケット: タスクをチケットとして定義し、対話のスコープを設定する 2. 対話の開始: 「解決して」ではなく 「議論したい」 と AI に投げる 3.【発散】原因追及: やり取りを重ね、根本原因や不明点を洗い出す 4.【収束】矛盾の排除: なぜなぜ分析で矛盾を潰す。矛盾が見つかれば 3 に戻る 5.【定義完了】仕様と方向性の合意: まだコード出力はさせない 6.【発散】実装: 合意できた段階で、初めて具体的なコード（差分）を出力 7.【収束】テスト: 実装を検証し、失敗すれば 6 に戻って作り直す 8.【監査完了】人間の監査: テストを通過した実装を、人間がレビューし承認する 9.【確定】Git へのコミット: 監査を通過した差分をコミットし、状態を確定 10.【知見化】アセット化: 要約をチケットに記録し、「ドメイン知識」として資産化 9 と 10 はダイヤモンドの外——設計思考のプロセスを終えたあとの、確定と記録のステップです。 AI を「単なる自動コーディング・マシーン」ではなく、 「デザイン思考の壁打ちパートナー」 として協業しましょう！ 14
15. 【Why】 あえて人間 なぜ完全丸投げにしないのか？ コードレビューやテストの網羅性チェックは AI でも可能。完全丸投げも技術的には可能になりつつあ ります。 しかし、AI は曖昧な「コンテキスト」を誤って解釈し、すでにリリースされている製品の機能が止まる ような、意図しない修正も平然とやってしまいます。 この暴走を食い止めシステムを守るため、人間が介在すべき最適な箇所が「レビュー」の段階です。 速さでも自動化でも、完全丸投げに軍配が上がります。それでも私たちが人間を挟むのは、この後の 3 つの理由からです。 15
16. 【Why】 あえて人間 あえて人間を残す、3 つの理由 1. 「責任」と「価値」の最終決定者だから AI はコードを生成できても、それが引き起こす結果（障害や事故）への責任は負えません。 レビューとは、変更を現実世界へ適用する「責任」を引き受けるための儀式です。 2. AI 同士の「共犯関係」の歯止めだから 生成 AI と評価 AI をどちらも AI に任せると、モデルが違っても学習データや設計の系譜が近く、似たバ イアスや死角を共有しやすくなります。 異なる次元の常識を持つ「人間」という異物を間に挟むのが、現状ではベターだと思います。 3. 「テキスト化されていないコンテキスト」の防衛線だから 現場の「明文化されていない過去の経緯」や「顧客の微妙なニュアンス」は、AI 同士のテキストのルー プでは徐々に削ぎ落とされます。 人間がレビューすることで、そのズレを検知できます。 【補足】組み込み開発ならではの事情 これは私の専門領域（センサ機器などの組み込みソフトウェア）に限った話ですが、実機での動作確認 は今の AI には任せづらく、コスト面でも大きな壁があります。これも、人間を介在させたい理由の一つ です。 16
17. 【Effect】 副次効果 小さな一歩と、対話の場 すべてのソフトウェア開発がそうとは限りませんが、最近は新規立ち上げよりも、既存のソフトウェア 資産をメンテナンス・インテグレーションしていく仕事が増えています。この場合、変更量自体は小さ く、その小さな範囲を確実に直すことが求められます。 チケットでスコープを絞り込むのは、巨大な計画に従うためではなく、 「小さく確実な一歩」を積み重 ねるためです。タスクがチケットとして切り出されているからこそ、 「どれならすぐに手をつけられそう か」「優先順位をどうすべきか」といった、プロジェクト進行そのものも AI に相談できます。 チケットは単なるタスク管理の入れ物ではありません。 「なぜこの実装/設計にしたか」を人と AI が直接 やり取りする 対話の場 でもあります。方針を固める段階からすでに始まっているからこそ、そこに至 るまでの 思考の跡 が残ります。 17
18. 【Effect】 副次効果 チケット化による資産化と、その中身 チケットが、会話と違って 流れて消えない からこそ、検索・参照・再利用できる 「アセット（資産）」 に自動的に変わります。 「要約をチケットに記録する作業」自体も AI に任せる ——人間は「どの議論を資産として残すべきか」 の采配（トリガー）を引くだけです。 • コンテキスト: 今このタスクに必要な、AI がまだ知らない背景や経緯。チケットに書き出して初めて AI に渡せる • アセット: その テキスト化されたコンテキスト が、チケット×コミットとして積み重なったストック • ドメイン知識: 両者をつなぐ実体。対話で生まれ、記録され、AI が後から検索・参照して獲得する 18
19. 【Effect】 副次効果 チケットは、いずれ「アセット」になる 🌳🎫 🕒 チケット #101 commit a1b2c3 🌳🎫 アセット：チケット×コミットの蓄積 チケット #102 commit d4e5f6 🌳🎫 チケット #103 commit g7h8i9 検索・参照する 👤 🧠 人間 （持っている知識） 📍 知識を持ち寄る AI AIが要約して記録 知識を得て、次の対話へ 🎫 コンテキスト：AIがまだ知らない背景 アクティブなチケット この「チケット×コミット」の履歴が積み重なることで、AI も人間も車輪の再発明をせずに済みます。 ※参考: 実行経験を wiki に蓄積しスキルへと進化させる手法を提案する論文「WikiSkill」でも、永続的な知識蓄積の重要性が指摘されている （arXiv:2608.27454） https://arxiv.org/abs/2608.27454 19
20. 【So What】 我々はどう変わるべきか？ エンジニアから「コンテキスト管理者」へ エンジニアの主務は「ゼロからコードを書くこと」ではなく、タスクをどう分割し、どこに境界線（チ ケット）を引くかという 「設計」 へと回帰していくのではないでしょうか。 AI に「適切な記憶（Git）」と「独立した境界線（チケット）」を与え、出力された差分（Diff）を監査・ 確定させる役割へと進化していくと考えています。 この役割は 二重構造 を持ちます。今のコンテキストを管理する ことに加え、積み上がったアセットと してのドメイン知識を育てる こと。この 2 つを担うのが 「コンテキスト管理者」 です。 20
21. まとめ • 出発点は「プロンプトを書くのが面倒」という、個人的な不満だった • チケットが対話の 「場」 を作り、レビュー が思考を絞る 「関所」 になる • インフラ構築の手間をかけずに、身軽な Vibe coding のまま開発プロセスへの統合ができる • チケットは会話の 「記録」 として蓄積され、いずれプロジェクトの「アセット（資産）」になる • 人間はコードを書く作業から、境界線を引き、差分を監査する「コンテキスト管理者」へと進化する 21
22. ご清聴ありがとうございました！ © 2026 tokudiro. This work is licensed under CC BY 4.0. 22