スキル

Curie:コーディングエージェントを同僚に変えるオープンソース・セルフホストプラットフォーム

開発チームが GitHub issue を AI コーディング同僚に委譲し、レビュー待ちの PR/MR を受け取るのに最適。利用には Docker/Kubernetes 環境と Anthropic または OpenRouter のモデルクレデンシャルを自分で用意する必要があります。

公式ソース · Curie

インストール

curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash

誰に向いているか

  • 自社インフラの中で AI 協働を使いたい開発チームに適しています:Curie はオープンソースでセルフホスト可能なプラットフォームで、自分たちのインフラ上で動き、コーディングエージェントを、タスクを任せて成果物を受け入れられる同僚へと変えます。
  • 中核となるシナリオは「GitHub issue を委譲し、レビュー待ちの実装を受け取る」こと:Curie が issue の実装とレビューを担い、チームの受け入れを待つ pull request または merge request を返します。
  • Kubernetes 運用との協働にも適しています:読み取り専用の Kubernetes チェックは即座に実行でき、設定済みの変更系操作は人間の承認を要求します。点検や診断といった低リスクの定常作業を任せるのに向いています。
  • 承認ステップを人間の手に残しておきたいチームに適しています:設定済みの変更操作には人間による再承認が必要で、どの操作に事前承認が必要かは自分で設定できます。
  • すでに自前のコーディングエージェントを運用しているチームは、公式の curie init --adopt ./my-existing-agent で既存エージェントを取り込めます。
  • 向いていないケース:Docker を動かせないマシンしかない、または Anthropic か OpenRouter のモデルクレデンシャルを用意できない場合です——公式に挙げられた実行前提はすべて必須です。

3分で最初の試行を完了する

前提:Docker が動作しているマシン1台に kind・kubectl・Helm をインストールし、Anthropic または OpenRouter のモデルクレデンシャルを用意します。どれか1つでも欠ければ、公式の手順どおりに開始できません。

ターミナルで公式インストールスクリプトを実行します:

curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash

スクリプトは Curie リポジトリの main ブランチから取得されます。パイプ形式のコマンドはリモートスクリプトをあなたのユーザー権限で直接実行するため、気になる場合は一度ダウンロードして内容を確認してから実行してください。

最初の試行は低リスクな道を選びます:説明が明確で影響範囲の小さいリポジトリの issue を1つ選び、実装とレビューを Curie に委譲します。完了すると、チームの受け入れを待つ pull request または merge request が返ってきます。成功のサインは明確です:コードホスティングプラットフォーム上で返された PR/MR を受け取り、その変更内容を1件ずつ確認できます。

インストール後にモデルクレデンシャルをどう登録するか、コードホスティングアカウントをどう紐付けるかは、公式説明に段階的な案内がなく、スクリプトの出力メッセージとリポジトリのドキュメントを参照してください。

使用例

ケース1:issue をレビュー待ちの PR に変える。状況:チームのリポジトリに、境界が明確な実装系の issue が滞留し、誰も手をつけられずにいる。始め方:その issue を Curie に委譲します。公式説明の「issue の実装とレビューを委譲」の流れに相当します。過程と結果:完了すると PR/MR が返され、自分のホスティングプラットフォーム上で変更を1件ずつレビューします。確認できるゴールは、チームの受け入れを待つ PR/MR を1つ受け取ることです。

ケース2:Kubernetes の読み取り専用点検。状況:クラスタの現在の状態を知りたいが、定常的なステータス確認のために変更承認フローを全部踏みたくない。始め方:Curie に読み取り専用の Kubernetes チェックを依頼します。使われるのは公式説明どおりの読み取り専用 Kubernetes ツールです。過程と結果:読み取り専用操作は即座に実行され、追加承認は不要です。その後で設定済みの変更系操作を求めると、まず新たな人間の承認を1回要求してから進みます。最初の点検を読み取り専用の範囲に留めれば承認待ちは発生しません。承認ステップを観察したい場合は、変更系の依頼を1つ追加すると承認プロンプトが表示されます。具体的にどの読み取り専用ツールが提供されるか、どう呼び出すかは、公式説明には列挙されていません。

利用の境界

  • 環境前提:Docker が動作中であること、kind・kubectl・Helm が揃っていること、Anthropic または OpenRouter のモデルクレデンシャルを持っていること。OS やハードウェアアーキテクチャの要件は公式には示されていません。
  • 副作用と確認ポイント:読み取り専用 Kubernetes ツールは即座に実行。設定済みの変更操作は毎回新たな人間の承認を1回要求。委譲した実装の出力はチームの受け入れを待つ PR/MR。インストールスクリプトがマシン上に何を作成し、どのディレクトリを占有するかは公式には一つ一つ説明されていないため、実行前にスクリプトの内容を確認しておけます。
  • 動作場所:セルフホスト型プラットフォームで、自分たちのインフラの中で動きます。
  • 既存エージェントの取り込み:公式は curie init --adopt ./my-existing-agent コマンドを提供しています。このコマンドが既存エージェントの何を保持するかは、公式説明には記載がありません。それ以外の初期化・設定の流れも公式説明では展開されていません。
  • 行動前にリポジトリで確認すべき情報:インストール後のクレデンシャル設定手順、コードホスティングアカウントの接続方法、利用可能な読み取り専用ツールと設定可能な変更操作の完全な一覧、この2社以外のモデルプロバイダに対応するか、そして接続できるコーディングエージェントの正確なリスト。手を動かす前に、1項目ずつリポジトリのドキュメントを基準にしてください。