きのこの美味しさに気づいちゃったカル太です。旨味ってすげぇ。

OpenCode で AI チームを作って開発するようになりました。気分はプロデューサーです。

今回は WSL2 上で OpenCode を立ち上げて作業している時の話を書きます。

が、その前に、OpenCode、開発環境であるコンテナ、そして herdr について軽く触れさせてください。

OpenCode って？

OpenCode はオープンソースの AI コーディングエージェントです。

ChatGPT や Gemini のようにテキストでのやり取りが可能ですが、PC 上のファイルを読み取ったり編集することで、開発も一緒にやってくれます。

OpenCode 自体がいろいろな AI モデルを仲介してくれているので、用途に合わせてモデルを使い分けたり、気になっていたモデルをちょっと試す、なんてこともできます。

使えるモデルは以下の通り。(2026/08/19現在)　後述になりますが、グラフの通りモデルごとに利用量が定められています。

とりあえず試したいという方ははじめにからインストールしましょう。

ちなみにデスクトップ版もあります。真っ黒な画面でキーボードを叩くのは趣味じゃないという方はこちらのが良いかも。

また、 OpenCode には従量課金制の Zen と、定額制だけど利用量に上限がある Go があります。

僕は現在 Go を利用中です。

コンテナって？

主な開発環境として Development Container （通称 devcontainer）を用意しています。

コンテナは PC 上に構築される、いくら壊してもOKな小さな箱庭だと思ってもらえたら良いです。

開発するための環境や道具が整っている上に、何度でも壊して作り直すことができます。

この箱庭の中で AI に活動してもらうことで、いくらファイルを壊しちゃっても、自分が持つ PC 本体には何の影響もないという感じです。

また、実際にサービスを稼働させる環境とほぼほぼ同じ状態で作業ができるので、

いざ本番でサービスを稼働させようとしても動かない！　手元の環境と本番の環境に差があるからだった！

みたいな事故の発生率もかなり小さくなるわけです。嬉しいですね。

herdr って？

herdr はターミナルマルチプレクサです。AI コーディングエージェント向けに作られたスグレモノ！

ひとめで稼働中の AI の様子が確認できちゃうんです。

そもそもターミナルマルチプレクサとは、1つのターミナル画面で複数の作業画面を同時に開いたり、ターミナルを閉じちゃっても裏で稼働し続けてくれるやつのことです。

WSL2 上で一度 herdr を立ち上げてしまえば、あとはこっちのもの。 PC に遠隔で接続できるような設定をしておけば、どこからでも AI エージェントの様子を見ることができるんです。

実際に使っている一番のポイントは、複数のリポジトリで AI を並列に走らせているときに、それぞれの様子を1画面で眺められることです。

ちょっと見づらいですが、こんな感じ。 Android と iPad から接続しています。

しかし devcontainer 上で稼働している AI エージェントには対応していないみたいで、作業が終わっても通知が来ず……。100％の力を発揮できずにいます。ちょっと残念。

と、色々と書いてきましたが、ここからが本題。

AI チームって？

ソフトウェア開発において、役割分担は必要不可欠です。

特に生成 AI ともなると、1人で全ての作業をこなそうとすると、途端にコンテキスト（ざっくり言うと AI が一度に覚えていられる会話や資料の量です）が溢れ、破綻してしまいます。

そこで、 AI 1人に任せるのではなく、それぞれが専門性を持った複数の生成 AI を組み合わせて、仲良く一緒に開発してもらおうというわけです。

頼れるメンバーをご紹介！

ここからはエージェントという機能を使って用意した、作業を丸投げしても文句一つ言わずにせっせと働いてくれる素敵なメンバーを紹介します。

まずは全体像から。

メンバーは、 Design・Implement・Knowledge の3つの現場ごとに分かれて働いています。

メンバー	担当と起用理由
Team leader GLM-5.2	情報の整理、作業内容のトリアージ、メンバーへの作業割り振りを担当。チームの中でも特に判断能力が必要なので、Z.ai のフラグシップ級モデルを起用
Requirement Analyst GPT-5.6 Luna	要件・制約・リスク・曖昧さの分析と、設計作業時に渡す情報の整理を担当。OpenAI の高速かつ低コストなモデルで、複雑な要求を紐解くのが得意そうな気がするため
Researcher Hy3	既存の知識・コード・アーキテクチャ・技術的制約の調査と、設計判断に必要な情報の提供を担当。Tencent Hunyuan 製で、推論から長文コンテキストまで重視して開発されているため。いまは利用可能量8倍期間中なのでお試し中
Tech lead DeepSeek V4 Pro	アーキテクチャや技術設計に関する判断と決定を担当（実装そのものはしない）。DeepSeek のフラグシップ級モデルで、複雑な推論やソフトウェア系のタスクに強いため
Implementer Muse Spark 1.2 Contributor	実装、テスト、修正を繰り返して動くところまで仕上げる担当。Meta 製のコーディングエージェント向けモデルで、ツールを使いながら長時間のタスクをこなせるため
Code reviewer DeepSeek V4 Flash	変更箇所から関連コードまで幅広く確認し、バグや設計上の問題を漏れなく拾う担当。V4 Pro には負けるけど十分なコーディング能力がある、高速かつ低コストなモデル
Docs writer GPT-5.6 Luna	設計をもとにプロジェクトのドキュメントを執筆する担当。利用量拡大期間中だったので採用。軽微なタスクでも使いやすい。ただ、いまは拡大期間の扱いが変わったようなので、モデルの変更を検討中……
Docs reviewer DeepSeek V4 Flash	執筆担当とは独立した立場で、設計との不整合や矛盾を確認する担当。高度な文章作成能力は不要と考えたため、高速かつ低コストで大量に利用できる

いくつか補足すると、

• Code reviewer を開発担当と別にしているのは、そもそも自己レビューは信用できないからです。
  • Docs writer と Docs reviewer の担当分けも同様の理由です。
• Imprementer (Muse Spark 1.2 Contributor) は利用内容がモデルの改善のために送信されます。
  • 企業で働いているときに触るセンシティブなものは扱わない運用なので、問題ないと判断しました。

という感じです。

ただ、これだけメンバーが揃っていても、どのように進めるべきかという指針がなければ、品質に差が出てきてしまいます。

そこで、なるべく高品質かつ路頭に迷わないための流れを用意しました。

ワークフローを skill として用意してみました

OpenCode には、再利用できる手順書をスキルとして登録できる仕組みがあります。今回はこれをチームの進め方ごと用意してみました。

やりたいことの設計をするための design と、設計をもとに実装する implement というスキルです。

大きく分けて、

• Design Skill

  1. 要求を整理する
  2. 既存の Architecture や ADR（Architecture Decision Record＝設計判断の記録）などの Knowledge を調査する
  3. Requirements と基本設計を分離する
  4. AI による設計レビューを行う
  5. 最終的には人間が設計を承認する
  6. 承認された設計をプロジェクトの Knowledge Base へ反映する

• Implement Skill

  1. 承認済みの Design の確認をする
  2. 実装を適度な大きさの Scope に分割する
  3. Scope ごとに「実装 → 検証 → レビュー → 修正」を繰り返す
  4. 全体の統合検証と AI による最終レビューを行う
  5. 最後は人間が変更全体を確認する
  6. 実装によって変化した Knowledge Base も調査・更新・レビューする

という流れです。

ちなみに Knowledge Base への反映は、設計の承認時と実装の完了後の合わせて 2 回行われます。

特に重視しているのが、AI に推測で仕様を決めさせないことです。

設計上の判断が必要になった場合は AI が勝手に進めず、人間に質問を残して Workflow を停止します。

また、 Design で決めたことを Implement が独自に変更することも禁止しています。

さらに、各 Agent が調査結果を会話のコンテキストで直接受け渡すのではなく、.ai/<タスク名>/ 以下のファイルに成果物として保存します。

イメージとしては以下のように、

という形で、「誰が何を判断し、どこまで確認された状態なのか」をファイルと Workflow の状態から追跡できるようにしています。

図の中にある AI レビューで引っかかった場合は、その時点で流れが止まって人間への質問が残されるので、勝手に先へ進むことはありません。

Agent を再起動したり、別の Agent に作業を引き継いだりしても、作業場である .ai/ に残された状態と成果物から Workflow を再開できるようになっています。

つまり、Skill を単純な「AI への指示書」ではなく、AI エージェントチームが従う開発プロセスそのものとして定義しています。

Design から Implement までを終えたときのタスク管理ディレクトリ配下はこんな感じ。

.ai/<タスク名>
├── design
│   ├── design.md          # Design における成果物
│   ├── questions.md       # 人間への質問が書かれている
│   ├── requirements.md
│   ├── research
│   │   └── <調査内容>.md
│   ├── review.md
│   └── state.md           # Design Workflow の状態管理
├── implement
│   ├── plan.md            # Implement の作業計画
│   ├── research
│   │   ├── <調査内容>.md
│   │   └── <取得データ>.json など
│   ├── retrospective.md   # 作業完了後の反省会結果
│   ├── review.md
│   ├── state.md           # Implement Workflow の状態管理
│   └── verification.md
├── reports
│   ├── <担当エージェント>-<報告内容>.md
│   └── scope-XXX-<対象領域>.md
└── team
    ├── agents.yaml        # チームメンバー
    └── tasks
        ├── <タスク内容>.md
        └── scope-XXX-<対象領域>.md

無駄な知識を持たせないためにも、参照すべきファイルはなるべく小さく作るようにお願いしています。

結果として、やってほしいことに対して正確な計画・設計・実装をやってくれてはいるのですが……

めちゃくちゃピンチ

こちらは現在の OpenCode Go のコンソール。月間利用量を見ていただきたい……。

残り25日もあるのに利用量が35％もいっちゃってます！

月間利用量は30日ごとにリセットされるとして、5日しか経ってないのに35％て！

このペースだと30日で上限の2倍以上になるくらい消費しちゃってるので、あと10日ほどしたら月間利用量が底をついてしまいます！

ということで、コンソールからはどのモデルがどれぐらい入出力のコストをかけたかが確認できるので、それをベースに偏りのあるモデルの入れ替えを検討しています。

現時点ではリーダーとなっている GLM-5.2 が利用量のほとんどを占めていたので、 Hy3 に交代してもらおうかなと思っています。

リーダーだからそんなに使わないと思っていたので油断していました。ぐぬぬ。

また、 OpenCode で利用できるモデルは結構な頻度で入れ替わるので、定期的にモデルの見直しは必要そうです。ここも自動化したいなあ。

必要な知識のお手入れも AI のお仕事なので

さきほどのように、利用できるモデルは結構な頻度で入れ替わります。だからこそ、誰が読んでも状況を掴める知識の土台があると助かります。

例えば、 Google が公開した Open Knowledge Format という形式に則ったドキュメント群を用意しています。

これを整備することで、リポジトリ内の全てのコードを確認することなく、概要や構成を把握し、知識を素早くキャッチアップできるようになります。

ちなみに、人間にも AI にも読みやすいドキュメントの構造を目指して考えられてるようです。

リポジトリ内のコードは現在を表しますが、変更差分を全確認して、なぜそうなっているのかなどを把握するのは困難です。

そこで、先述のドキュメント群に、なぜそうしたのかの記録を残しつつ、古すぎて不要そうな情報を消す、なんてこともやっています。

これは主に AI チームの Docs writer と Docs reviewer の仕事ですね。ドキュメントは腐りやすいものなので、ここも AI 任せにしちゃっています。ラクで楽しい。

さらに、ナレッジベースだけじゃなく skill 自体にも手を入れています。

例えば、コードの命名に迷ったときのための規約や、日本語のドキュメントの書き方の指針、説明的な文章に緩急をつけるためのガイドなどを skill として用意していて、チーム全員の行動規範になっています。

メンバーごとのばらつきが減って、アウトプットの品質が安定するのが嬉しいところです。

まとめ

OpenCode と devcontainer を利用して、AI が好きに動ける環境を用意したら楽しいよというお話でした。

OpenCode はありがたいことに無料枠も用意されていて、使っている限りでは24時間ごとに利用量がリセットされていそうなので、それだけでも多少は遊べると思います。

（AI チームを用意するような使い方だったら結構すぐに無料枠を使い切っちゃうと思いますが……）

とりあえず試してみたいなというそこのあなた！

こちらのリンクから OpenCode Go の契約をすると、5ドル分の利用クレジットが得られます。僕にも5ドル入ってきます。そうなったらとても嬉しいので、是非とも試してみてほしいです。

それでは、今日はこのへんで。