Jira、GitHub、社内Wiki、ターミナル、そして複数のAIコーディングエージェント。業務システムの開発現場で、これらを行き来するためにブラウザタブが10個以上開いている状況に心当たりがあるなら、ツール統合の設計思想を知っておく価値があります。
今回扱うのはDevHubというオープンソースのデスクトップアプリです。タスク管理、ノート、プルリクエスト（コード変更をレビューのために提案する仕組み）、リポジトリ、AIコーディングエージェントを1つのウィンドウにまとめる設計になっています。個人開発者が自分用に作ったツールですが、既存の業務システム開発チームが社内ツールを選定・自作する際の判断材料として参考になる点が複数あります。
DevHubは何を解決しようとしているか
DevHubの基本構造は「ローカルダッシュボード」です。データはすべて自分のマシン上にファイルとして保存されます。
GitHubやJira、Googleカレンダーとの連携はすべてオプション扱いです。Jiraを接続しなければJira関連の画面自体が表示されません。
この設計は、業務システムの現場でよくある「全部入りSaaS（複数テナントで共同利用するクラウドサービス）を契約したのに結局2割の機能しか使わない」という問題への対処法として理解できます。必要な連携だけを有効化し、不要な画面を増やさない構成です。
主要な画面構成は次の通りです。
- Today: 当日のタスク、エージェントに任せられる計画、朝の要約、カレンダー
- Work: 全タスクの一覧とタグ・日付・ステータスでの絞り込み、週次レビュー
- Notes: デイリーノートや会議メモ、プロジェクト記録をタスクやPRと相互リンク
- PRs: 自分のプルリクエストとレビュー待ちの一覧
- Databases: SQLite、PostgreSQL、MongoDBへの接続画面
Cmd+P / Ctrl+P で任意の項目にジャンプできる機能も用意されています。VS Codeのコマンドパレットに慣れたエンジニアには馴染みやすい操作感です。
エージェント統合の仕組みを分解する
DevHubで最も作り込まれているのがAIエージェント統合の部分です。段階的に見ていきます。
まずPaseoという小さなローカルヘルパー（補助プログラム）が組み込まれており、これを経由してClaude Code、Codex、Cursor、OpenCode、Copilotといった複数のコーディングエージェントにアプリ内からチャットできます。サインイン情報を読み取れる場合は、各サブスクリプションの利用量も表示されるため、使いすぎによる想定外の請求を避けやすくなっています。
次に「Skills」という機能です。スキルとは再利用可能な指示セットのことで、一度書けばClaude Code、Codex、Cursor、OpenCode、Antigravityの各エージェントに自動的にコピーされます。
これは業務システム開発でよくある課題、つまり「チームごとに異なるAIツールを使っていて、コーディング規約の徹底がツールの数だけ必要になる」問題への対応です。Personaタブでは同様にエンジニアリング標準を共有でき、「My voice」という機能で文章のトーンをエージェントに学習させることもできます。
さらにDevHub自体がMCP（Model Context Protocol、AIエージェントが外部ツールを呼び出すための標準規格）ツールを公開しています。これによりエージェント側からDevHubの機能を直接呼び出せるため、画面間のコピー&ペースト作業が減る設計です。
権限設計の考え方は参考にしやすい
業務システムの保守運用という観点で最も注目すべきはここです。人間が操作する場合とエージェントが操作する場合で、承認フローを明確に分けています。
人間がJiraチケットを動かす操作は1クリックで完結します。確認ダイアログを挟まない設計です。
一方、エージェントが何かを変更しようとする場合は必ずレビューのステップが挟まります。チケットやPRへの提案内容、送信先が画面に表示され、実際に送信される前に人間が確認する仕組みです。
具体的には次のような制約が設けられています。
- 中断されたコマンドは黙って再実行されない
- 組み込みブラウザでは、制御を渡した時だけエージェントが読み取りを行える
- クリックや入力値、ファイル転送はそれぞれ個別の承認が必要
- PRレビューの結果はノートとして保存されるだけで、GitHubへの投稿は自動化されない
この非対称設計は、社内の承認ワークフローシステムを設計する際にそのまま応用できる考え方です。「誰が」ではなく「何が引き金になった操作か」で承認レベルを変える発想は、RBAC（ロールベースアクセス制御）だけでは防ぎきれない自動化エラーへの備えになります。
既存システムとの統合可能性をどう見るか
DevHubはJiraとGitHubを前提に作られていますが、特定のワークフローに固定されない設計も意識されています。プラグインシステムがその中核です。
プラグインはdevhub-plugin.jsonというファイルを含む独立したリポジトリとして作成します。スキルやエージェント、MCPサーバー、ダッシュボード画面、データベース接続などを追加できる仕組みです。
アプリ内では「Plugins」からGitHubのURLを貼り付け、追加される内容を確認してから有効化します。ソースからビルドする場合は次のコマンドで操作できます。
npm run plugins -- add <path-to-the-plugin>
npm run plugins -- listこの仕組みにより、特定企業だけに意味のある業務ロジックを共有コードから切り離せます。社内特有のワークフローをプラグイン側に閉じ込め、コアは汎用のまま保つという構成です。
業務システムの開発チームがこの種のツールを評価する際は、次の観点を確認するとよいでしょう。
- データの保存場所がローカルかクラウドか（セキュリティポリシーとの整合性）
- 既存のJira・GitHub・Backlogなど社内で使っている管理ツールとの連携可否
- エージェントへの権限付与が業務フロー単位で制御できるか
- プラグインやカスタマイズの仕組みが社内特有の承認フローに対応できるか
今日から確認できること
すでに複数のAIコーディングエージェントを併用しているチームであれば、まず自分たちの現状を棚卸しすることから始められます。
チームで使っているエージェント（Claude Code、Copilot、Cursorなど）ごとに、コーディング規約やレビュー観点の指示をどう管理しているかを確認してみてください。ツールごとに別々の設定ファイルを手作業で揃えているなら、Skills的な「1箇所で書いて複数ツールに配布する」仕組みの導入余地があります。
また、現在運用しているAI支援ツールが、人間の操作とエージェントの操作を同じ承認フローで扱っていないか確認する価値があります。エージェントによる外部システムへの書き込み（チケット更新・PR送信・Slack投稿など）に、人間の操作と同等の確認ステップしか設けられていない場合、誤操作時の影響範囲を見直す機会になります。
まとめ
DevHubはあくまで個人発の小規模プロジェクトで、エンタープライズ利用を前提とした実績が豊富にあるわけではありません。ただし、その設計思想には業務システム開発の現場で流用できる考え方がいくつも含まれています。
- 連携をオプション化し、使わない機能を画面に出さないことで「全部入りツール疲れ」を避ける設計
- AIエージェントへの指示（スキル・標準）を一元管理し、ツールごとの設定の重複を防ぐ発想
- 人間の操作とエージェントの操作で承認の摩擦を変える非対称設計
- プラグインで企業固有のロジックをコアから分離し、保守性を保つ構成
自社のツールチェーンを見直す際は、まず現在使っているAI支援ツールの権限設計がエージェント操作と人間操作を区別できているかを確認してみてください。その上で、社内ワークフローの汎用部分と固有部分をどう切り分けるか、プラグイン的な発想で整理し直すことが次の一歩になります。