2026年7月30日(木)、株式会社ベクトルの代表・石川氏によるオンライン勉強会が開催されました。その中で披露されたのが、自社開発の革新的なAI開発制御ツール「vk orchestrator」です。

近年、ClaudeやCodexをはじめとする高精度なコード生成AI・Agentic AIの登場により、AIにプログラミング作業を自律実行させることが当たり前の時代となりました。しかし、それに伴い「複数のプロジェクトやIssueをどう並列でAIに処理させるか」「トークン制限や人間の確認待ちをどう制御するか」といったプログラミング以外のタスク運用上の課題が浮き彫りになってきています。

本記事では、勉強会で明かされた「vk orchestrator」の全貌、その構造と画期的な仕組み、そして本ツールが示す「これからのソフトウェア開発の未来」について、約3,000字で分かりやすく解説します。

筆者の作業PCにインストールした vk orchestrator

関連リンク一覧

1. ツール紹介:「vk orchestrator」とは?

開発背景と全体概要

vk orchestrator は、GitHubのIssueをトリガーにして、AIエージェントによるコード実装・テスト・修正作業を自動的にキューイング(行列化)し、並列かつ効率的に進行・制御するためのオーケストレーションツールです。

従来のように、人間が手動でAIチャット画面を開き、「このファイルを直して」「次はあのバグを直して」と指示を出すスタイルでは、同時に進行できる作業数に限界があります。また、複数プロジェクトを抱える開発チームでは、どのIssueが処理中で、どのIssueがAIの作業完了待ち・人間の確認待ちかが煩雑になりがちでした。

vk orchestrator は、こうした「AI主導開発のマルチタスク進行」に伴う混乱を収束させ、“人間がIssueを起票してラベルを貼るだけで、複数のAIターミナルが勝手にタスクを消化していくシステム”を実現します。

「VK Orchestrator」を形作る3つの主要コンポーネント

勉強会のスライドによれば、本システムは大きく分けて以下の3つの要素で構成されています。

コンポーネント名概要と役割
VK Agents作業を実行するAIのルール、プロンプト、使用モデル、利用可能スキル等の各種設定(例:vk-kore などのエージェントスキル)
VK TerminalsAIが実際にコードを読み書きし、CLIコマンドやシェルを実行するためのGUIターミナル実行環境
VK Orchestratorタスクの巡回、優先度管理、トークン残量管理、全体進行の自動制御を担うバックエンド/コントロールシステム

タスク処理の基本ワークフロー:「受付票」モデル

vk orchestrator の最もスマートな仕組みが、「専用リポジトリのIssueを受付票にする」というアイデアです。

【処理の流れ】

  1. タスクの標識付け開発者が各プロジェクト(リポジトリ)のIssueに対し、タスクキュー登録用の「特定ラベル」を付与します(チーム運用時は担当ユーザーを自分に設定)。
  2. オーケストレーターの定期巡回vk orchestrator がGitHubを定期的に巡回(ポーリング)し、タスクキュー用のラベルが貼られたIssueを自動検出します。
  3. 受付票(タスクキューIssue)の起票自動処理対象のIssueを見つけると、全体管理用の「専用タスクキューリポジトリ」の中に同名のIssue(受付票)を自動作成します。中身には元のIssueへのリンクや処理用メタデータが記録されます。
  4. VK Terminals へのジョブ投入受付票の情報(対象URL、適用するAIスキル、並列設定、優先度等)をもとに、VK Terminals のAPIへタスクを発注。AIエージェントが自動的にコーディングを開始します。

受付票(タスクキューIssue)に持たせる主なメタ情報

AIが安全かつ迷わずに作業を開始・完遂できるよう、受付票には以下のような制御フラグが細かく管理されます。

  • アサインユーザー: 担当するエンジニア
  • 作業対象 Issue の URL: 実際に修正を行うソースコードリポジトリ側の課題ページ
  • 作業ステータス: 「実行中」「並列可」「手動マージ待ち」「完了」など
  • 実行モード: 並列(Parallel)で同時に実行してよいか、順番(Sequential)に実行すべきか
  • 優先度(Priority): 割り込み実行が必要な高優先度タスクかどうか
  • 自動マージ可否: AIが作成したPull Requestを自動マージして良いか、人間が確認すべきか

2. 「vk orchestrator」の画期的な部分

① プロジェクト横断の作業を「専用受付票リポジトリ」で一元化

複数の自社製品や受託案件を並行開発している場合、各プロジェクトのリポジトリにIssueが散乱し、どのAIがどこで何を動かしているのかを全元把握するのが難しくなります。

vk orchestrator は、あえて「タスクキュー専用のリポジトリ」を1つ挟み、そこに全プロジェクトからの発注票を流し込む形を採っています。これにより、ダッシュボード感覚で全案件のAI稼働状況・順番待ちが一目瞭然になります。

② 「トークンリミット」と「人間の割り込み」の現実的制御

AIエージェント開発における最大の壁は、「APIのトークン上限(レートリミット / コスト制限)」「途中で人間の判定・認証を挟む必要があること」の2点です。

vk orchestrator のGUI画面では、以下の情報がクリアに視認化・制御されています。

  • トークン消費量の可視化: ClaudeやCodex等の週間/日間の使用率(例:「今週 26% 使用済み」「今日 9.4M トークン」など)を常時モニタリング。
  • リミット回避のキューイング: 「トークンリミットの都合で今は走らせられない」タスクを自動で後回し(キュー待ち)にし、枠がリセットされたタイミングで自動再開。
  • 人間の入力待ちの見える化: 権限昇格(bypass permissions)やMCPサーバーの認証が必要になった際、どのタスクが人間側の入力を待っているかが即座に分かります。

③ 複数モデル・複数端末による「マルチAI並列実行環境」

デモ画面では、複数のターミナルパネルが並び、一方で Claude (Opus 5 / 1M context) を走らせ、もう一方のパネルで別案件(bill-vektor のIssueなど)を同時進行させている様子が示されました。

AIに指示を出して待つ「レスポンス待ち時間」を完全にゼロにし、人間は「進行状況のログを眺め、要所で承認ボタンを押すだけ」という、あたかも「AIエンジニア集団を統率する監督」のような開発スタイルを可能にしています。

3. 今後起こりそうなこと(AI開発の未来と展望)

「vk orchestrator」のようなツールの出現は、単なる作業効率化にとどまらず、ソフトウェア開発の現場やエンジニアの役割そのものを根本から変容させると予想されます。

1. エンジニアの定義が「プログラマー」から「AI工場のオーケストレーター」へ

これまでのエンジニアの主要業務は「コードを書くこと(Syntax & Logic)」でした。しかし今後は、以下のような上流設計と工程管理がメイン業務になります。

  • Issueの解像度向上: AIが正確に動けるように、仕様や背景、テスト条件をIssueに明確に記述するプロンプトエンジニアリング能力。
  • リソースマネジメント: タスクの優先度(Priority)付けや、どのモデル(軽量モデルか最高峰モデルか)に処理させるかの判断。
  • レビューと最終品質保証: AIが自動生成したPull Requestの内容の監査。

2. 「夜間・休日」における完全自律型リファクタリングの定着

トークンリミットの制限を「空き時間(夜間など)にキュー消化させる」という思想は、今後の開発の標準になります。

人間が眠っている間に、オーケストレーターが優先度の低い技術負債の解消、ライブラリのアップデート、テストコードの追加、ドキュメント生成などのIssueを片っ端から自動処理し、朝起きたときには承認待ちのPRがずらりと並んでいる——そのような24時間不休の自律開発環境が現実のものとなります。

3. Open Source / OSS コミュニティへの劇的な波及

ベクトルのようなオープンソースプロダクト(WordPressテーマ・プラグイン等)を展開する企業にとって、Issue管理とAI処理の連動は革命的です。

外部のコントリビューターやユーザーから寄せられたバグ報告(Issue)に対し、オーケストレーターが一次検証を行い、簡単な修正であれば自動でPRを作成。コミッターは内容を確認してマージするだけで済むため、OSSプロジェクトの進化速度と保守品質が格段に向上するでしょう。

まとめ

株式会社ベクトルの「vk orchestrator」は、AIにコードを書かせる段階(第一世代のAI活用)から、「多数のAIをいかに束ね、システムとして連携・運用するか(第二世代のAIオーケストレーション)」へとフェーズが移行したことを象徴するツールです。

「タスクキューリポジトリを受付票にする」というシンプルながら強力な設計思想、そしてトークン管理や並列実行の現実的課題をクリアするアプローチは、今後のAIネイティブな開発現場における標準モデルとなっていくことは間違いありません。

GitHubリポジトリ(vektor-inc/vk-orchestrator)の動向を含め、今後のさらなる進化に要注目です。

By tokita