🌟

C3LとClaude hooksの破壊力 - 永久開発機関の完成

に公開
hooks
Claude Code
c3l
tech

自動化した結果

朝から自動で開発サイクルが周っていく。

git graph

夕方も引き続き。
git graph2

自動化 : Claude hooks の出番

昨日 C3L プロジェクト固有のAI呼び出し言語を作成したことで、Claude hooks の活躍シーンが来ました。

公式のHooks referenceは少し難解ですが、実際に試してみることで理解が深まりました。

1. Stop の利用

Claude Code が作業を完了すると「Stop」が発動します。

このタイミングで Climpt の言語選択を使い、次の作業を選択させます。
意味のない無限ループに陥らないよう、プロジェクトで取りうるアクションリストを事前に用意しておくことが重要です。

実行イメージ:
Stop working

2. 自動実行の前に

あらゆる選択が自動で進むと、問題も起こります。
問題を抱えたまま突き進まないよう、まずは手動実行で、安定した開発サイクルを確立しておくことが大切です。

例えば、次のようなアクションが日常的に発生します。
これら全てに対し、人間の修正を介さず、AIのみで作業完結できる状態が必要です。

  • ドメイン設計
  • 要件定義
  • 詳細化
  • 開発
  • テスト
  • コミット
  • PRからマージ
  • 仕掛かりブランチの選択
  • GitHub Issueからの選択

もちろん、Migrationや外部API連携、Docker構築など難易度の高い作業も含まれます。

これら全てを「AIのみで完了できる」ことが、完全自動化のスタート地点となります。

なお、今日の時点では、「開発、テスト、コミット、PRからマージ、仕掛かりブランチの選択」までが自動化できています。残りは、単体実行であればAIのみでできる、あるいは、「できる感触がある」状態です。もうちょいです。

3. 自動実行の精度向上

ひとまず、ある程度は全自動で動く状態になりました。
しかし、これで終わりではありません。
プロジェクト進行の精度を上げていく必要があります。

精度UPは、プロジェクトの言語定義を厳格化することで、実現できると考えています。
定義の厳格化によって、次に取りうるアクションが明確になり、誤りの少ない自動化が実現できます。試しにGit系の整備をC3Lで行ったところ、重要な改善がみられました。

プロジェクトの言語定義には、
1.一貫したコマンド生成ルール
2.ルールに合わせたコマンドの実装
の2点が必要です。

まず、C3L定義によって、はじめて一貫したコマンド生成が可能となりました。C3L v0.3をChatGPT-5やClaude Opusに取り込むことで、コマンド名の提案も安定します。この作業は、都度の定義では実現できませんでした。

次に、コマンドの追加や統合もClimptなら容易です。自動実行がうまくいかない場面が生じても、比較的柔軟に対応できます。（Denoの利点です。）

ちなみに、Claude Code には Custom slash commands という、概念的には使える機能があります。柔軟性がイマイチなのですが、MCPコマンドで内部的に呼び出すと、1と2は実現できると思います。（私は試していません）

次に取り組むこと

1. 並列 tmux の廃止

AI出力コードを収束させる方法： ドメイン駆動設計 & 全域性 & テスト駆動 & Claude Code Companyの考え方を見直し、Claude Code Companyを外すことにしました。
今は、作業が止まることなく自動化できているため、複数の作業者（Claude Code）を立てるだけで十分と判断しました。
コンテクストの維持を伴う状態のままですから、物量よりも安定性を優先します。（別作業での並列稼働はできますから、物量はどうにでもなります）

2. 難しい局面の判断を磨く

Migrationや破壊的変更への対処プロセスを整備する必要があります。GitHub Issueのラベル付けやProjectの活用など、悩ましい部分も多いです。
これらをプロジェクト言語で操作できる点は、Climpt/C3Lの強みであり、最適化の伸び代が十分あると感じています。コーディングだけでなく、同じ方法を要件定義や仕様策定にも適用でき、一貫性があるためです。しかも、Denoツールを1ついれるだけの、非常にシンプルな構成で、持ち運び可能です。

難しい局面については、習熟のために、（自分以外の）他のプロジェクトでも試してみたいと、少しだけ感じています。

3. 他プロジェクトとの協調

現在、バックエンド側で自動化を整えています。
今後は、フロントエンドのレポジトリを別で動かしながら、バックエンドと協調する方法も模索します。

現状のフロントエンドは、ブランチを参照してAPI仕様書を取得できているので、すぐに困るものではありません。
しかし、破壊的変更の追随や、設計段階でのプロジェクト相互関与をどうするかは、今後の課題です。バージョン違いの開発を並列化するようなケースまでは、まだハンドリングのイメージが持てません。

いよいよ整ってきた感

まだ課題はあるものの、基礎的なサイクルや、要求・ドメイン定義が整った環境では、コード開発の完全自動化が現実のものとなってきました。

今後は、要求から要件化への精度を高めるため、Issue作成の自動化にも取り組んでいきます。

やっと・・というべきか、いよいよというべきか。
整ってきた感があります。

Discussion