Issueに「@takt run」をコメントするだけ。AIエージェントオーケストレーションツールをGithubに統合してみた。
告知
実際にオーケストレーションする様子をデモしたり、使い方をお話するイベントをすることにしました！
オンラインで行いますので是非お越しください！
はじめに
前回の記事では、taktのレビューを並列化して待ち時間を短縮した話をしました。
takt #99 とコマンドを打てばIssueが片付く。並列レビューで待ち時間も半分になった。素晴らしい日々です。
しかし、ひとつだけ気になることがありました。
taktを実行するには、自分のPCでターミナルを開いてコマンドを打つ必要があります。当たり前のことではあるのですが、タスクをいくつも回していくとPCが重くなります。外出中に「あ、あのIssueやっておきたいな」と思っても、手元にPCがなければ何もできません。
どうにかならないものでしょうか。
taktがGitHub Actionsに統合された
そこで作ったのが takt-action です。
takt-actionは、GitHub Actionsでtaktを動かすためのカスタムアクションです。PRが作られたときに自動でレビューを走らせる使い方も考えてますが、今回はもっと面白い使い方を紹介します。GitHubのIssueにコメントするだけでtaktのワークフローが実行されるのです。
使い方はとてもシンプルです。Issueのコメント欄に次のように書くだけです。
@takt run
たったこれだけで、GitHub Actionsが起動します。デフォルトのワークフローでは、taktがIssueの内容を読み取り、計画を立て、実装し、レビューし、修正し、最終確認まで自動で進めてくれます。完了するとPRが作られるので、あとはレビューしてマージするだけです。
ワークフローを指定することもできます。
@takt run simple
こうすれば simple ワークフローで実行されます。指定しなければ default ワークフローが使われます。
組み込み方
実際にどうやってリポジトリに組み込むのかを見てみましょう。taktのリポジトリ自体がtakt-actionを使っているので、そのワークフローファイルを参考にします。
実際のYAMLは次のとおりです。
name: TAKT Action
on:
issue_comment:
types: [created]
jobs:
takt:
# Uncomment to allow organization members or collaborators:
# || github.event.comment.author_association == 'MEMBER'
# || github.event.comment.author_association == 'COLLABORATOR'
if: |
contains(github.event.comment.body, '@takt') &&
github.event.comment.author_association == 'OWNER'
runs-on: ubuntu-latest
permissions:
issues: write
contents: write
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: nrslib/takt-action@main
with:
anthropic_api_key: ${{ secrets.TAKT_ANTHROPIC_API_KEY }}
model: ${{ vars.TAKT_MODEL }}
github_token: ${{ secrets.GITHUB_TOKEN }}
log_output: ${{ vars.TAKT_LOG_OUTPUT || 'false' }}
ポイントをいくつか説明します。
まず on: issue_comment です。Issueにコメントが作成されたタイミングでワークフローが起動します。
次に if の条件です。コメント本文に @takt が含まれていること、そしてコメントしたのがリポジトリのオーナーであることを確認しています。誰でもtaktを実行できてしまっては困りますからね。オーナー以外にも、組織のメンバーやコラボレーターにも許可を出すことができます。YAMLのコメントに書いてあるので、必要に応じて有効にしてみてください。
permissions では、Issueへのコメント書き込み、コードのプッシュ、PRの作成に必要な権限を指定しています。
そして nrslib/takt-action@main でtakt-actionを呼び出します。anthropic_api_key にはAnthropicのAPIキーを、github_token にはGitHubのトークンを渡します。APIキーはリポジトリのSecretsに登録しておく必要があります。
リポジトリの設定で「Allow GitHub Actions to create and approve pull requests」を有効にしておくのも忘れないでください。これがないとPRを作成できません。Settings → Actions → General から設定できます。
セットアップはこれだけです。思ったよりも簡単ではないでしょうか。
ちなみに、このYAMLにはSlack通知のステップも含めることができます。taktの実行が完了したらSlackに通知が飛ぶようにしておけば、外出中でも「あ、終わったな」と分かります。ありがたいですね。
実際に動かしてみた
では、実際に動かしてみた例を見てみましょう。
このIssueに対して @takt run とコメントしました。すると、GitHub Actionsが起動して、taktがワークフローを実行し始めます。
実行結果はActionsのログから確認できます。
ここでひとつ気づいた方もいるかもしれません。taktのログ、出ていないですよね。
これは意図的にそうしています。log_output を false にしているからです。
なぜログを出さないのか。基本的にtaktは秘匿情報を出力しないはずなのですが、AIがいつ何を出してくるかは分かりません。APIキーやトークンのような情報がログに混入するリスクをゼロにはできないのです。GitHub Actionsのログは、リポジトリにアクセスできる人なら誰でも見られます。パブリックリポジトリなら全世界に公開されます。
そういうわけで、デフォルトではAIのログは出さないようにしています。現在、ログは出さずに進捗だけが分かるような仕組みに修正中です。
さて、ログの展望はさておき、結果はこのようにPRとして作られます。
今回は簡単なタスクでしたね。もちろん複雑なタスクもこなしてくれます。
何が変わったか
さて、takt-actionを導入して何が変わったのでしょうか。
これまでの開発フローを振り返ってみましょう。
まず、自分のPCでターミナルを開きます。taktのコマンドを実行します。ワークフローが走っている間、PCのリソースを使います。いくつものタスクを並行して進めていくと、PCが重くなります。外出中にはそもそも実行できません。
takt-actionを導入したあとはどうでしょう。
家にいるときも、外出中でも、スマホからGitHubのIssueを開いて（Issueがなければ作っちゃいましょう！ AIと相談して貼り付けるのもよいです！） @takt run とコメントするだけです。
あとはGitHub Actionsのランナーがすべてやってくれます。PRができあがったら通知が来るので、コードを見て、大したことなければそのままマージ。大きな変更であれば、自分の環境にpullして動作確認してからマージ。
つまり、「コメントポチー → PRレビュー → マージ」という流れになったわけです。
自分のPCのリソースを使わないのも嬉しいポイントです。taktのワークフローはそれなりに時間がかかることがあるので、その間PCを占有されないのは助かります。
料金の話
ここで避けて通れない話をしましょう。料金です。
もりもりお金が溶けていきます。
さきほどのIssueを実装する前の請求ダッシュボードは以下のクレジットがありました。
そしておわったあとは……。
$340.51-$338.63=$1.88。日本円でだいたい300円。まぁ時給を考えると安いかな。
もちろんこちらの金額はタスクの複雑さによって変わっていきます。takt-actionはAPIキーを使ってClaude Codeを動かしています。つまり、ワークフローの実行中に発生するAPI呼び出しは、すべてAPIキーの課金対象です。
計画、実装、レビュー、修正と、ワークフローの各ステップでAPIが呼ばれます。レビューが複数回ループすれば、その分だけ課金も増えます。
ちょっとしたタスクでもそれなりの金額になることもあります。Claude CodeをAPIキーで使うということは、そういうことです。
ではサブスクリプション（Claude Code Max Planなど）をGitHub Actionsで使えばいいのではないか、と考える方もいるかもしれません。しかし、ビジネスでCI/CDパイプラインでサブスクリプションを使うのはアウト寄りのグレーのようです。利用規約上、自動実行がサブスクリプションの想定用途に含まれるかは明確ではありません。個人のみが利用していると言えるのであればそうではないようですが……判断はお任せします。
というわけで、使い分けが大事になります。
ここでtaktのワークフローが活きてきます。
taktにはビルトインで複数のワークフローが用意されています。simple は計画→実装→レビュー→承認のシンプルな流れで、修正ループがありません。default は多段レビュー＋並列レビュー＋修正ループ付きのフルスペックです。ステップ数が違えば、当然API呼び出しの回数も違います。
たとえば、READMEの更新やtypo修正のような軽微なタスクに default ワークフローをフルで回すのはもったいないですよね。そういうときはワークフローをつくって @takt run fix-typo とコメントすれば十分です。逆に、設計から多角的にレビューしてほしい機能開発なら default や expert を使う。そしてとても重いタスク、たとえば大規模なリファクタリングや複雑な新機能の実装は、ローカルで takt #99 を実行する。
こうすれば、コストとクオリティのバランスを自分でコントロールできます。
さらに言えば、CI専用の軽量ワークフローを自分で作ることもできます。レビューをひとつに絞る、修正ループの回数を制限する、使うモデルを変えるなど、YAMLを書き換えるだけです。コスト最適化のためのワークフローを用意するというのも、taktのワークフローが自由に定義・選択できるからこそできることです。
まとめると、こんな使い分けになります。
- 軽微な修正（README更新、typo修正など）→
@takt run simpleでCI実行 - 通常の機能開発 →
@takt run（default）でCI実行 - 重いタスク（大規模リファクタ、複雑な新機能）→ ローカルで
takt #99
やっぱりローカルかなぁ、と思う場面も正直あります。しかし、「どこからでもIssueにコメントするだけで開発が進む」という体験は、コストを払ってでも手に入れたいものでした。タスクの重さに合わせてワークフローを選べるのが、その判断を楽にしてくれています。
ところで、あれ？ これってDevin……？
ここまで読んでくださった皆さん、お気づきでしょうか。
Issueを立てて、コメントして、自動でコードが書かれて、PRが作られて、レビューしてマージする。
あれ？ これって、Devinでは……？
そうなのです。やっていることはDevinにかなり近いのです。Devinは独自のAIエージェントを内蔵していますが、takt-actionはClaude CodeやOpenAI Codexをバックエンドとして使っています。既存のAIコーディングツールの上に乗っかっている形です。
ここが面白いところだと思っています。
依存しているからこそ、敷居が低いのです。
すでにClaude Codeを使って開発している方なら、taktをインストールして、takt-actionのワークフローYAMLをリポジトリに追加するだけで、Devinに近い体験が手に入ります。新しいサービスに登録する必要もなければ、専用のインフラを用意する必要もありません。
もちろん、Devinのような洗練されたUIや高度な機能とは比べるべくもないでしょう。しかし、「Issueからコードが生まれてPRになる」という体験そのものは、同じ方向を向いています。
しかも、taktはワークフローを自分で定義できます。どんなエージェントがどんな順番でどんなレビューをするのか、すべて自分でコントロールできる。これはこれで、なかなか魅力的ではないでしょうか。
まとめ
taktがGitHub Actionsに統合されました。Issueに @takt run とコメントするだけで、AIエージェントのオーケストレーションが自動で走り、PRが作られます。
セットアップもシンプルです。ワークフローYAMLを追加して、APIキーをSecretsに登録するだけ。あとはIssueにコメントすれば、どこからでも開発が進みます。
料金はそれなりにかかります。APIキーで動かしている以上、そこは覚悟が必要です。ローカルとの使い分けをすればなかなか現実的ですし、経営の観点でもIRRを超えるラインがあるはずです。うまい使い方を見出していきましょう。
「コメントポチーで開発が進む」という体験は、一度味わうと戻れなくなりますからね！
takt-actionはまだまだ開発中です。PRのdiffをレビューコンテキストとして渡す機能や、レビュー結果をPRのインラインコメントとして投稿する機能など、やりたいことはたくさんあります。
興味を持っていただけた方は、ぜひ試してみてください。
Discussion