Archonは、AIコーディングエージェント(Claude・Codexなど)の作業手順をYAMLワークフローとして定義し、決定論的かつ再現可能に実行させるためのハーネス構築ツールです。CLIからワークフローを起動し、プラン作成・実装・レビュー・PR作成といったSDLCの各工程を自動化します。SlackやDiscord、GitHubなどの外部チャネルからもリモートでエージェントを操作できる仕組みも備えています。
中核は「ワークフロー(.yaml)」と「コマンド(.md)」の組で、`.archon/workflows/`配下にplan・implement・review・pr・shipなど工程別のYAMLが並び、各ノードがbunスクリプトやClaude/Codexへの呼び出しを実行します。`maintainer-standup`の例では、gitステータス取得・GitHub PR/issue取得・過去コンテキスト読み込みの3スクリプトを並列実行し、その結果をClaude Sonnetの合成ノードが読み込んでP1〜P4の優先度分類とdirection.mdとの整合判定を行い、`{brief_markdown, next_state}`という構造化出力を返します。最後の永続化ノードがブリーフをMarkdownファイルへ、次回用状態をstate.jsonへ書き込みます。設定は`~/.archon/config.yaml`(個人・機種共通)、`.archon/config.yaml`(プロジェクト共通)、`--config`指定の実行時オーバーライドの3層構造になっており、未知キーはエラーになる厳格設計です。マーケットプレイス由来のスクリプトは`marketplace-security-scan.ts`でRCEや資格情報漏えいパターンをテストフィクスチャ付きで静的検査しています。SlackアダプターはBolt SDKのSocket Modeでメッセージを送受信し、ワークフローの実行状況(ノードごとの状態・コスト・トークン数)をBlock Kitで整形して通知します。デプロイ面ではDockerfileが3段構成(依存インストール→Web UIビルド→本番イメージ)で、auth-serviceというNode.js製の別コンテナがbcryptとHMAC署名クッキーでCaddyのforward_auth用サイドカー認証を担っています。
- STEP 01
まず`.archon/maintainer-standup/profile.md.example`を`profile.md`にコピーし、gh_handleやroleを自分用に書き換える作業が最初のステップになります。
- STEP 02
`archon workflow run maintainer-standup ""`を実行すると、`origin/dev`のfetchとfast-forward、GitHub CLI経由でのPR・issue取得が並列で走る様子が見えます。
- STEP 03
初回実行では過去状態がないため「baseline」扱いとなり、2回目以降で`state.json`との差分から「前回からの解決済み項目」が表示される変化を体感できます。
- STEP 04
YAMLワークフローを`.archon/workflows/sdlc/`配下のplan・implement・review・pr・shipの各ファイルで追うと、1つの機能追加がどの順でノードを通過するかを`fixtures/*.stubs.yaml`のスタブ入出力から先読みできます。
- STEP 05
Dockerで動かす場合は3段ビルド(bun install→Vite/Reactビルド→本番イメージ)を通すため、初回ビルドがripgrepやChromiumのインストールを含み比較的時間がかかります。
- STEP 06
Slack連携を試すと、`SLACK_ALLOWED_USER_IDS`のホワイトリスト設定次第でオープンアクセスか制限アクセスかが切り替わる挙動を確認できます。
実行後に手元へ残るのは、`briefs/YYYY-MM-DD.md`という日次ブリーフと`state.json`という次回比較用の状態ファイルです。SDLCワークフローを回す場合は、plan・implement・review・PR作成までの各工程の実行ログとGitHub上のPR・レビューコメントが成果物になります。マーケットプレイススクリプトの検査結果は、悪性パターン検出テストのpass/failとしてCIログに残ります。
メンテナースタンドアップは`worktree.enabled: false`でライブチェックアウト上で動くため、`--branch`や`--no-worktree`は使えず、実行中に作業ディレクトリの状態が変わる前提を理解しておく必要があります。
AI合成ノードの分類(P1〜P4)は`direction.md`の記述に依存するため、この文書を整備しないと優先度判定の精度が下がると考えられます。
auth-serviceのパスワードハッシュ生成コマンドをREADME・コード内コメントに沿って事前に用意しないと、サーバー起動時に環境変数不足でプロセスが終了する設計になっています。
legacyやexperimentalディレクトリのワークフローが多数存在し、どれが現行のSDLC標準(`sdlc/`配下)かを見分けるのに慣れが必要です。
GitHub上でのPRレビューやissue対応を日常的に回すメンテナー、またAIコーディングエージェントの手順を再現可能な形で固定したいチームには適した選択肢です。YAMLワークフローとコマンドMarkdownの分離、3層設定、マーケットプレイススクリプトの静的検査、Slackアダプターの実装まで、ファイル構成とコードの記述が一貫して同じ設計思想(決定論性・状態の明示的永続化・厳格な設定検証)を反映しているため、README記載の挙動と実コードの整合性は高いと判断できます。ただし個人の単発コーディング支援というより、複数人・複数リポジトリで運用ルールを共有するチーム向けの重量級ハーネスである点は踏まえておくべきです。