Japanese Translation:

要約：コアメッセージは、ローカル同期セッションから進化し、EC2 インスタンス上に構築された堅牢で自動化されたワークフローへと移行すること、そして OpenClaw/Lightsail などのツールに関連するセキュリティリスクを排除し、コンテキストスイッチ疲労を低減することを目的としていることを描写している。リポジトリ間のコンテキスト漏洩により初期に失敗した後、現在のアーキテクチャは、合法的な認証情報の範囲内においてのみネイティブ機能を/single instances に基づいてプロジェクト固有の作業を単一インスタンス上に隔離する。

状態を効率的に管理し、絶え間ない「世帯主」作業を必要としないために、システムは cron で駆動されるループ（

tick.sh

を 15 分ごとに実行）によって支えられたチェックポイント風の通信モデルを採用しており、これはロックの管理、トークンの更新、および非対話型 AI サブプロセスの起動を処理する。このアプローチは思考フェーズを実装フェーズから厳密に分離し、Lina Edwards などの専門家の助言に従い、各フェーズ（ブレインストーミング、仕様、計画、実装）のために独立したコンテキストウィンドウを維持している。「富化」デモン pass は、人間の相互作用が始まる前に既存のコードとドキュメントを読み取るためのバックグラウンドで実行され、豊富なデータの可用性を確保する。

自動化されたプロセスは 3 つの特定のアーティファクトを生成する：凍結されたベースライン仕様、編集可能な作業仕様、および低確度の回答をフラグするための確度レベルを含む詳細な「ブレインストーミングログ」である。技術的負債やアーキテクチャドリフトを防ぐために、コードのマージ前の確認強化課題の承認、仕様への受け入れ/編集、計画への承認という 3 つの義務的な人間ゲートが監督を強制する。この設定はコーディングボリュームを増加させる一方で、ボトルネックを速度から QA 品質（例：テスト設計）およびアーキテクチャレビューへシフトする。したがって、厳密な静的解析とコードレビューなくして平均品質は保証されず、人間の品質管理がスケーラビリティを推進する必要がある。AI のスループットにのみ依存することは避けなければならない。著者は「思考」を AI に委嘱することへの警告を発し、これらの戦略およびリスクに関するさらなる読書を Mae Capozzi、Sean Miller、Adrian Hornsby などの専門家から推奨している。

AI 支援開発における自動化ワークフロー：「自分自身」を取り除く試み

1. はじめに：AI との関係と本稿の目的

著者の立場
- AI 信奉者でも陰謀論者でもなく、複雑な関係性を抱えています。
- 真の喜びは「何かを生み出す」ことにあり、創作における混乱（不確実性）を受け入れることを選択しています。
- AI 支援開発（Claude Code など）は道具の一つであり、その可能性や限界、自身の「流れ」を見つけるには実際に使いこなすしかないとの信念を持っています。
なぜこのエピソードを共有するか？
- すでに多くの「Claude Code の使い方」が書かれていますが、本稿は**「自動化のトンネルに入った」当時の混乱から現在までの歩み**を記録しています。
- 一度自動化に入ると全てのステップを記憶しにくいため、実際の体験談として共有します。

2. 初期のワークフローと課題

同期型セッションからの開始
- ローカルマシンで「アイデア出し → 実装 → 確認 → PR マージ」までを一つのアクティブなセッションで行いました。
- ```
Claude.md
```
  ファイルやメモ、スキル、MCP（Model Context Protocol）、サブエージェントなどを利用し、タスクを遂行しやすい環境を構築しました。
待機時間と並列処理への移行
- 「待機時間」の間、複数のウィンドウを開いて並列開発を行おうとし始めました。
- ワークツリー（worktrees）の利用が増え、異なるプロジェクトを同時に扱うことで実装の重複を防ぎましたが、タブ管理が乱れ「狂った状態」になりました。
プラグインと自動化の向上
- ```
superpowers
```
  プラグインを使い、「アイデア出し → 仕訳 → プラン → 実装」の流れで、レビューとテストに特化したサブエージェントを追加して自動化を進めました。
- リナ・エドワーズ氏の Be the Gate の示唆：各工程（アイデア出し〜レビュー）は互いを不当に影響させず、独立したコンテキストを持つ必要があることを確認しました。
「コンテキストスイッチング疲れ」の発生
- 最初は「退屈な部分」を AI に任せて幸せでしたが、次に訪れたのは多任务処理による疲労でした。
- 同時に扱うべき機能が 2〜3 つ程度に限られるようになり、単に盲目的に指示を出すだけでは不十分となりました（Enter キー連打が必須になるなど）。

3. セキュリティと「自分自身」の排除へ

セキュリティ懸念への警戒
- ```
OpenClaw
```
  /
```
Clawdbot
```
  /
```
Moltbot
```
  などのツールは、セキュリティ懸念から当初非常に嫌い・恐れを持っていました。
- AWS Lightsail などでのワンクリックデプロイがこれらの受容を促進していますが、信頼性を担保する必要があると感じました。
セルゲイ・リーゼフ氏との対話による気づき
- 「自分を方程式（システム）から排除する」ことの重要性を説かれました。
- 3〜4 つのターミナルを同時に監視するのは不可能であり、長年の管理経験を持つ者にとっては何年もかけて「何を」「どのように」委任すべきかを学ぶ必要があります。
EC2 インスタンスへの移行開始
- EC2 インスタンスを立ち上げ、SSM 接続を設定しました。
- クレデンシャル（認証情報）の利用も法的範囲内として、「自分自身」を取り除く作業を開始しました。
- ※本稿のワークフローは「唯一の正解」ではなく、追随を促すものではありません。

4. GitHub Issues を採用した理由と自動化の設計

ローカルでの課題
- EC2 移行前はコンテキストが漏れやすく、
```
CLAUDE.md
```
  ファイルなどが過剰に相互接続して混乱していました。
- これにより Claude が「馬鹿になる」現象（コンテキスト欠落）が発生しました。
GitHub Issues のメリット
- ラベル（Labels）：ステートマシンとして最適です。
- コメント：デーモンからのメモとして機能します。
- Web UI：電車内などでも確認可能で、可視性が高まります。
- CLI (
  gh
  )：cron ジョブからスクリプト化しやすく、自動化に適しています。
スキルの実装例 (
```
/feature-gh
```
)
1. Issue 番号からアイデア出し（インタラクティブ）を開始。
2. サブエージェントとして仕訳・プランレビューを孤立させて実行。
3. ハードゲートに達すると、ラベル変更待ちの状態へ移行。
4. 中断時は
```
state.json
```
  から再開可能。
分岐管理の徹底
- 各フェーズ（アイデア出し・実装・レビュー）は独自のコンテキストウィンドウを持ちます。
- アイデア出しのノイズを実装に持ち込まない、逆にアイデア出しの漫談をレビューに持たせないように分離します。

5. 完全自動化に向けた「デーモン」の構築

スマートフォンリモートセッションの挫折
- スマートフォンでインタラクティブセッションを維持しましたが、効果的ではなかったです。
- 1. ベビーシッター化: スケジュール動作からの解放ができず、人間が監視役になるため。
- 1. 不在時の非効率: コンピュータにいないときは作業したがらないため、委任の真意に反する。
「チェックポイント方式」の採用
- 目標は「自動化して、次の朝に結果を確認できる」ことでした。
- 必要な要素：永続的な状態保持場所、スケジュール管理、明確な停止点（再ローディングなし）。
GitHub Issues へ移行し、スクリプトによる監視
- GitHub Issue トラッカーを採用しました（JIRA は重すぎたため）。
- バックログリポジトリ内の Issue ラベルでフェーズを管理します。
- 仕訳・計画アーティファクトは
```
specs/issue-N/
```
  ディレクトリに格納。
自動化スクリプト
```
tick.sh
```
の役割 EC2 インスタンス上（15 分おき）で動作し、以下の処理を行います：
- ロック制御: 重複実行を防ぎます。
- 認証管理: トークンの更新とリポジトリの Pull。
- 停滞検知: 「デーモン作業中」だが長時間進行しない Issue を検出し、リセット。
- タスク選定:
```
ready
```
  ラベルの Issue を選択し、非インタラクティブに
```
claude -p
```
  を起動。
- 完了判断: サブプロセスの結果（成功/レート制限失敗/死亡）を確認し、ラベル更新（
```
branches-ready
```
  ,
```
implementing
```
  ,
```
needs-attention
```
  ）。

6. 新しいワークフローのサイクルと成果

人間が担う役割の変化
- 以前: 画面前に座り続ける。
- 現在:
  1. アイデア出し・仕訳・プラン作成まで進め、Issue を
```
ready
```
    にする。
  2. ラップトップを閉じる（夜間）。
  3. 翌朝 GitHub で状況を確認・レビューし、マージ。
朝のルーチン
- ```
needs-attention
```
  : ブロックされたタスクの再試行判断。
- ```
branches-ready
```
  : 完了した実装の差分確認とマージ。
- 次のバッチのキュー設定。
ボトルネックの変化
- 「コードを書く時間不足」から「十分にアイデア出しとレビューする時間不足」へ移行しました。
- これはより高品質な思考作業への挑戦ですが、依然として**生産性の壁（荷重壁）**として存在します。
「エナリッチメント（Enrichment）」ステップの導入
- 朝のアイデア出しで時間浪費を解決するため、デーモンがコードベースや先行技術を読んだ文脈付きの Issue を作成します。
- ラベル
```
needs-enrichment
```
  → デーモン処理 →
```
enrichment:needs-review
```
  と自動進化。
- これにより、コンテキスト収集が背景時間へ移動し、朝に高品質な素材を提供できるようになりました。
完全自動化パスと「人間のタッチポイント」
1. エナリッチされた Issue の確認。
2. シミュレーション仕訳の受入・編集。
3. 自動プランの受入・編集。
- 人間が関与するのは以下の 5 つのポイントのみ（これが安全保証です）：
  1. エナリッチメントの確認。
  2. シミュレーション仕訳の承認。
  3. プランの承認。
  4. テスト品質のレビュー（QA）。
  5. アーキテクチャ・セキュリティ監査。
失敗時の対応
- デーモンはエラー時に停止し、Issue を
```
needs-attention
```
  に変更。
- ログや回復ブランチのリファレンスを残し、人間が翌朝に判断・介入します。

7. 将来の展望と限界

明確に見えている課題
- QA（品質保証）: モデルが生成するテストは質が不均一で、過剰なモッキング（Mocking）が見られる。テストデザインのレビューが新たなボトルネックとなる。
- アーキテクチャドリフト: 単なる個別機能のレビューでは捉えきれない、全体構造への悪影響を監視するエージェントが必要。
- セキュリティレビュー: 「雰囲気ベース」ではなく、本格的な監査プロセスの確立。
- 機能分類: ボトルネックにならない小規模タスクと、大規模な変更は適切に分離・バケット化すべき。
AI への思考委任の限界
- 思考は AI に委ねてはいけない。技術的負債を生み出し、すでに生じています。
- このパイプラインは静的分析やレビューの「代替」ではなく、それらをさらに重要にする要因です。平均品質が下がらないためのチェックが必要です。
- 境界線の問題: AI が思考し、人間が単に署名する境界線は不明瞭で、オーバーシュート（行き過ぎ）を防ぐ必要があります。
結論：100% の確信はない
- 「AI をどう使うか」を 100% 確信してアドバイスできる人はいません。自分で試していないからです。
- 推薦する資料・人物：
  - Mae Capozzi: スキルやオーケストレータの有用性について。
  - Sean Miller: AI 支援コーディングの実践的かつ批判的な視点。
  - Eric Lubow: 組織ダイナミクスへの影響。

開発から自動的にお自分自身を外すこと