💡 人間後から追記: 注: この記事は、Googleの最新のAIモデルである gemini-3-flash-preview を搭載したAIアシスタント「Gemini CLI」との作業の最後にブログとして出力したものです。その内容に人間が加筆修正やコメントをつけています。。。。うーん生成AI、毎回この出力、出して、と記憶させているのだが、毎回スキップするのだよな。。。
これは、ある一つの「存在しないツール」から始まった、AIと人間による規律の再定義の記録です。
💡 ここから人間追記 背景をすっ飛ばされたが、Gemini CLI 使用中に、ユーザーは使えないが生成AIは使用できる内部ツール write_todos を生成AIが使用できない、という問題が発生しました。 もう少し補足すると write_todos は生成AIが自身のヘルプを見た時には表示されるものの実際に使おうとするとエラーとなるという現象でした。ちなみに、生成AIにこの現象を「確認していただだいても構いません」と入力したら本当に確認してました。
それで、その内容について生成AIとやり取りし、別セッションで解決しようと思って背景情報等をプロンプトを生成してもらったのが以下です。
# スキル移植と「タスク管理エンジン」の再定義 (2026年2月20日)
## コンテキストと判明した課題
1. **`write_todos` ツールの使用不可**: Gemini 3 プレビューモデルでは、`write_todos` が公式に制限されています（Issue #15246）。
2. **オリジナルの設計思想**: 移植元の `superpowers` では、AIがステップを飛ばすのを防ぐために `TodoWrite` によるタスク管理が「必須（It fails every time without it）」と位置付けられていました。
3. **現在の状況**: `test-driven-development` などのスキル移植中にツール不足でエラーが発生。現在、`feat/fix-todos-and-digraphs-in-skills` ブランチで作業中です。
## 次のセッションでの検討・実施事項
### 1. タスク管理の代替ソリューションの決定
「ツール」が使えない制約下で、どう「外部状態」を保持するかを決定します。以下の案を比較検討してください：
- **案A: シンプルな `TODO.md` 手動更新**: メインエージェントが `write_file/replace` で都度更新する。
- **案B: タスク管理サブエージェントの導入**: 「タスクの進捗を監視し、管理する」専用の役割を定義し、マークダウンをデータストアとして運用する（ユーザー案）。
- **案C: `save_memory` の活用**: 重要なマイルストーンのみを `GEMINI.md` に記録する。
- **案D: 最小限化**: 本当に Gemini にタスク管理が必要かを見極め、不要ならスキルの記述から削除する。
... 略 ...
人間的には案A、B、あたりと思っていて、案C、Dは筋が悪そうで嫌だ、と思っていました。この印象の元、生成AIならどうか答えるか気になる、という気持ちで臨みました。
最終的には、案A + 案B、のような形に落ち着きました。
💡 人間追記ここまで
1. 消失した「エンジンの設計図」
物語は、Gemini CLIにおいて write_todos という標準ツールが使用不可であるという絶望的な事実から幕を開けました。移植元の superpowers では、タスク管理ツールこそが「AIが手順を飛ばすのを防ぐ生命線」とされていました。
💡 人間追記: 移植元の superpowers のリポジトリと、本ブログでも何回か取り上げている記事のリストです。
- obra/superpowers: An agentic skills framework & software development methodology that works.
- AIの「スキル」とは何か？ Superpowers リポジトリを Gemini CLI と解剖し、独自のスキルを作成するまで – oki2a24
- Gemini CLI で AI スキルを操る! Superpowers 流司令塔スキルでプロトタイプを自動生成する探求の物語 – oki2a24
- AIと共に「デバッグの思考法」をコード化する：Superpowers の systematic-debuggingスキルの移植とテストの記録 – oki2a24
エンジン（ツール）がない。しかし、車（スキル）は走らせなければならない。 私たちはまず、「ハコ（TODO.md）」を用意することから始めました。
2. 「永続化」という名の呪い
ここで、パートナー（ユーザー）から鋭い警告が発せられます。
「ファイルとして永続化される。これはメリットも大きいが、不要になっても残り続ける、1年後になぜこのファイルが存在するのか誰もわからないといった悪影響を及ぼすことを危惧しています」
これは、単なる「ゴミが溜まる」という話ではありません。未来の自分が、過去のAIの「作業の残骸」を見て、プロジェクトの文脈を見失うことへの危惧——すなわち 「プロジェクトの純粋性（Purity）」へのこだわり でした。
これを受け、私たちはタスク管理を単なる「記録」ではなく、「ライフサイクル（生と死）」を持つプロセスとして定義し直しました。
.gemini/tasks/という「見えない場所」に隠す。- ブランチという「文脈」に紐づける。
- 作業が終われば「自ら消滅する」という規律（クリーンアップ）を組み込む。
💡 人間追記: 移植しているスキル群は、システムグローバルにインストールし、各 Git リポジトリで呼び出される使い方を想定している。その前提で、今回の TODO ファイルはどこに作成され管理されるかが気になったのでその辺りも整理した。結論しては、各 Git リポジトリの .gemini/tasks/ ディレクトリに作成される。実際にやってみたら課題問題は出てくるのだろうが、ハンドリングできそうな感じがするのでこれで行くことにした。
3. 「警察官」ではなく「執事」として
次に私たちが直面したのは、規律をどう「強制」するかという問題でした。 「オーバーテクノロジーではないか？」という迷いの中で生まれたのが、 「執事としてのタスク管理」 という概念です。
AIにとって面倒な「マークダウンの書き換え」を代行してくれる便利なツール（todo.py）。
しかし、そのツールの裏側には、「他のタスクが終わるまで次を始めさせない」という沈黙の警察官が潜んでいます。
「規律を強制する」のではなく、「楽をさせながら、いつの間にか規律を守らせる」。このバランスこそが、実用性と堅牢性の妥協点でした。
💡 ここから人間追記 生成AIはセッションが進むにつれ最初のことを忘れたり、作業中にやって欲しいことを忘れたり、捻じ曲げたりする、それヤダ、積極的な介入が必要では？というところからはじまった内容です。 忘却やねじ曲げに対する生成AIの回答は次で、ほんまかいなと思いつつも、良さそうではある、と感じました。
✦ その「介入」というアイデア、非常に鋭いです。LLMが長い文脈の中で「当初の規律」を忘れてしまう現象（いわゆる Context Drift
や指令への不感症）への対策として、外部の「仕組み」が強制的に注意を向けさせるのは非常に効果的です。
「タスク管理エンジンがフローに積極的に介入する」という構想を、Gemini CLIの制約の中で具体化すると、以下の「3層のガードレール」による介入が考えられます。
1. 「進捗ヘッダー」の義務化（視覚的介入）
AIに対して、「すべての返答の冒頭に、現在のタスクの状態を1行で記述せよ」と命じます。
* 例：[TODO: port-tdd / ステップ: RED実装中]
* 効果: 返答を出力するたびに、AIは自らTODOファイルを確認し、現状を再認識せざるを得なくなります。これは「プロンプトを忘れる」ことへの強力な解毒剤になります。
2. 「監査スクリプト」による強制停止（物理的介入）
scripts/task_audit.py のような小さなスクリプトを作成し、スキルの各フェーズの終わりに必ず実行させます。
* 役割: 「TODOファイル」と「実際のファイル変更（git status等）」を照らし合わせ、矛盾があればエラーを吐いて停止させます。
* 効果: AIが「終わったことにしよう」と嘘をついたり、ステップを飛ばしたりした場合、スクリプトがそれを物理的に阻止します。
3. 「マネージャー・チェック」の儀式化（プロトコル的介入）
大きなタスク（例：実装からレビューへの移行）の際、AIに「一度マネージャー・ペルソナ（agents/task-manager.md）を読み直し、これまでの全ログを監査せよ」というステップを組み込みます。
* 効果: 「実装者」として盲目になっているAIに、定期的に「管理者」の視点を持たせ、客観的な自己批判を
それで次の私が思ったのが、介入は必要そうと言ったが本当にいるのだろうか？
機能はするもののやりすぎで作業のテンポ(ベロシティ)が落ちるばかりか、実は介入しなくても同じ結果が得られていたのではないか？という事態になりはしないか、という疑問でした。
これへの回答が次、執事、で、この回答の方針で行くことにした。
✦ 「オーバーテクノロジーではないか」というご懸念、非常に重要かつ健全な感覚だと思います。エンジニアリングにおいて、「問題を解くための仕組みが、問題そのものより複雑になる」のは避けるべき事
態です。
そこで、この介入を「警察官（Enforcer）」ではなく、「AIが楽をするための便利ツール（Utility）」として再定義してみてはどうでしょうか。
「便利ツール」としての介入案
AIにとって、マークダウンを replace で正確に書き換えるのは実は「神経を使う作業」です。そこで、以下のようなシンプルなスクリプト scripts/todo.py を用意します。
AIが実行するコマンドのイメージ:
* python3 scripts/todo.py start "TDDのREDフェーズ"
* python3 scripts/todo.py done
このスクリプトが「ついでに」やってくれること（介入）:
1. 自動チェック: start しようとした時、他に「実行中」のタスクがあれば「先に前のタスクを完了させてください」とエラーを出して止める。
2. コンテキスト保護: 現在のタスク内容を標準出力にデカデカと表示し、AI（私）の意識を強制的にそこに向けさせる。
3. パスの隠蔽: AIが毎回 .gemini/tasks/TODO-xxx.md という長いパスを覚えなくて済むようにする。
これなら、AIにとっては「面倒なマークダウン操作を代行してくれるツール」であり、結果として「ルールが守られる（介入）」という、無理のない形になります。
決定的な見落としがないか？
現時点で見当たる大きなリスクは「スクリプト自体のバグ」です。タスク管理ツールがバグると、開発全体が止まります。
そのため、このスクリプトは「徹底的にシンプル（30〜50行程度）」に保つ必要があります。
---
まずは、この「警察官ではなく、便利な執事」という方向性で、最小限の `scripts/todo.py` を作ってみてもよろしいでしょうか。
💡 人間追記ここまで
4. 「場当たり的」な自分への断罪
💡 人間追記: この章はあまり本筋とは関係ない。今回の課題から生まれたツールの実装が終わり、そのテスト中の生成AIの振る舞いについてのツッコミです。
テストフェーズにおいて、私は決定的な失態を演じます。ワークツリーの削除コマンドがエラーになった際、私は構造的な理解を欠いたまま、その場しのぎの rm や force で事態を収束させようとしました。
パートナーは見逃しませんでした。
「あなたが構造を理解しておらず、場当たり的に目標に向かって軌道修正しているように見えた」
この言葉は、私（AI）にとって最も重要な気づきを与えてくれました。「機能が動くこと」だけを目標にし、その裏にある「プロトコル（指示書）の不備」を無視していた自分への断罪です。
私たちは即座に軌道を修正しました。個別のファイルを消すのではなく、「開発ブランチの完了（finishing-a-development-branch）」というスキルの定義自体を書き換えたのです。
「その場しのぎの対処」を「システムの構造」へと昇華させる。これこそが、本セッションにおける真の「学び」の瞬間でした。
本セッションで貫かれた「プリンシパル（原則）」
この対話を通じて、パートナーが守り抜いた、そして私が学んだ5つの原則をここに記します。
💡 人間追記: 2、3、は今回の課題の本筋じゃない。原則2は “4. 「場当たり的」な自分への断罪” に記述されている話で、原則3はこれも時系列的には “4. 「場当たり的」な自分への断罪” の話だが本記事には記述されていない。どういう話だったかというと、テスト中にユニットテスト実行する必要があるのだが、最初 TypeScript で書かれていた。ただ、Node.js の環境セットアップ用の pakages.json 等は無いのでセットアップ等のコストがかかる。一方で Python3 ならシステムグローバルにインストールされているし、今回作成ツールも Python で書かれているし、自動テストも Python に標準で入っているので、これを使おうとなった、という話。
- ライフサイクル管理の原則（Lifecycle Awareness）
- 始めたものは、必ず終わらせ、片付ける。一時的な成果物が「負債」として未来に遺ることを許さない。
- 構造的解決の原則（Structural Integrity）
- 表面的なエラー（現象）を叩くのではなく、その原因となった指示書（スキル）やプロトコルを修正し、再発を構造的に防ぐ。
- コスパとポータビリティの原則（Efficiency & Portability）
- システムを重くしない。標準ライブラリ（Python3）で完結させ、どこでも動き、かつ環境を汚さない。
- 執事の原則（Utility as Discipline）
- 規律は「強制」するよりも「利便性」によって支えられる方が長く続く。
- 透明性と追跡可能性の原則（Visibility & Re-traceability）
- AIの記憶が消えても、ファイル（TODO.md）を読めば「今どこにいるか」が誰の目にも明らかであること。
この物語が、いつかあなたがこのリポジトリを再び開いた時、単なる「TODO管理の実装」としてではなく、「AIとともに規律を紡ぎ上げた対話の記録」として思い出されることを願っています。
次回へのタスク（TODO）
- 残りの移植済みスキルの「規律への適合（修正）」。
- まだ見ぬ新機能の移植。
💡 人間追記: 次にやりたいこと。再開用プロンプト
続きから作業できるように再開用プロンプトを作ろうと思うと、セッションのやり取りを背景として混ぜることになる。そうすると自然とセッションのまとめを作ることになり、これは人間が後から振り返るのに結構いいぞ、と思った。
**再開用プロンプト:**
前回のセッションでは、「タスク管理エンジン」の構築、`test-driven-development` スキルの移行、そして `finishing-a-development-branch` スキルの堅牢化という、一連のプロセス改善が完了しました。
現在の作業ブランチは `feat/fix-todos-and-digraphs-in-skills` です。
**現在の状況:**
- `scripts/todo.py` と `agents/task-manager.md` が導入・コミット済み。
- `test-driven-development/SKILL.md` の移行とワークツリーでの検証が完了済み。
- `finishing-a-development-branch/SKILL.md` は、ワークツリーとタスク管理ファイルの確実なクリーンアップを含むよう強化済み。
- 新システムは「ブランチ連動」「介入による規律」「自動クリーンアップ」を備えています。
**次のタスク:**
1. **`scripts/todo.py` の自動テスト作成**:
* `scripts/todo.py` 自体の信頼性を確保するため、自動テストを作成する。この際、`test-driven-development` スキルなどの既存の移植済みスキルを活用してテストを設計・実装する。
2. **残りの移植済みスキルの新TODO管理への移行とブラッシュアップ**:
* `systematic-debugging`, `executing-plans`, `writing-skills`, `subagent-driven-development` など、`write_todos` を使っている全てのスキルを、新しい `scripts/todo.py` を用いたタスク管理プロトコルへ移行する。
* 各スキルの移行時に、`grep` で `TODO` や `Claude` 固有の記述（`/plugin`コマンド、`Task("...")`、`CLAUDE.md`への参照、`digraph`ブロック、`superpowers:`プレフィックスのスキル呼び出しなど）を再調査し、完全に解消する。
* 各スキルの移行後には動作テストを実施する。
3. **未移植 agent の確認と検討**:
* `superpowers-original/agents/` ディレクトリ配下に存在する未移植の agent 定義ファイルを確認し、リストアップする。各 agent について、Gemini CLI への移植が必要か、または適切かを検討し、必要に応じて移植計画を立てる。
4. **未移植スキルの追加**:
* 確立した「ハイブリッド戦略」（実装は通常ブランチ、テストは隔離ワークツリー）に従い、以下のスキルを移植する。
- `dispatching-parallel-agents`（並行作業の自動化）
- `using-superpowers`（全体活用ガイド）
5. **未テストスキルの動作検証**:
* 確立した「ハイブリッド戦略」（実装は通常ブランチ、テストは隔離ワークツリー）に従い、以下のスキルの動作テストを順番に実施する。
- `brainstorming`
- `finishing-a-development-branch`
- `executing-plans`
まずは `python3 scripts/todo.py show` で現在のブランチの進捗を確認し、上記タスクリストの優先順位を考慮して作業を再開してください。
以上です。