14｜AI Work Governanceと既存ツールは、どこが同じでどこが違うのか

Linear・GitHub Projects・Spec Kit・Backstage・LangGraph・OpenHandsとの責務比較

AI Work Governance｜比較リファレンス

Linear、GitHub Projects、Spec Kit、Backstage、LangGraph、OpenHands。

AIとソフトウェア開発の仕事を整理しようとすると、似た機能を持つ既存ツールがいくつも見つかります。

では、このシリーズで扱っている AI Work Governance（AI-WG） は、それらと何が違うのでしょうか。

ここで大切なのは、「同じ機能がある」ことと「同じ責務を持つ」ことを分けることです。

flowchart LR
    accTitle: 既存ツール比較の三段階
    accDescr: 似た機能があるか、同じ責務を持つか、そのまま置き換えられるかを順に分けて比較する。
    A[似た機能がある?] --> B[同じ責務を持つ?]
    B --> C[そのまま置き換えられる?]

似た能力がある
  ≠
同じ責務を持つ
  ≠
そのまま置き換えられる

この記事では、製品の優劣ではなく、どの責務を外部ツールへ任せ、どの意味を手元に残すかという観点で比較します。

先に、AI Work Governanceで残したいもの

このシリーズではAI-WGを、特定の製品や実行環境ではなく、AIと進める仕事の意味を継続して扱うための設計として説明しています。

人間の意図
  ↓
仕事の目的 / 正本 / 権限
  ↓
作業項目 / 状態 / 判断履歴
  ↓
再利用手順 / 証拠 / 検証
  ↓
AI実行役や外部ツール

外部ツールへ任せやすいのは、たとえば次です。

• 作業一覧やロードマップの表示
• ワークフローの実行
• コーディング作業
• 保存・検索
• 可視化

一方、ツールを交換しても失いたくないのは次の意味です。

• 何を達成する仕事なのか
• 何を正しい情報として扱うのか
• 誰が何を決めてよいのか
• なぜその判断になったのか
• どの証拠で成立したと言えるのか
• 別のAIや実行環境へどう仕事を持ち越すのか

flowchart TB
    accTitle: 外部ツールへ任せても残したい仕事の意味
    accDescr: 人間の意図と判断から、正本、権限、証拠、判断履歴という仕事の意味を残し、その下で作業管理、ワークフロー、コーディング、知識保存の各ツールを利用する構造を示す。
    H[人間の意図 / 判断]
    H --> S[残す仕事の意味]
    S --> C[正本 / 権限 / 証拠 / 判断履歴]
    C --> X1[作業管理UI]
    C --> X2[ワークフロー実行環境]
    C --> X3[コーディング実行役]
    C --> X4[知識・保存ツール]

Linear — 仕事を見渡す計画・進捗画面として近い

LinearはIssue、Project、Initiativeなどを使って仕事を整理し、目標と進捗を追うための製品です。

AI-WGと重なるのは、

• 作業項目を整理する
• プロジェクトや目標単位で俯瞰する
• 状態や優先度を見る

といった部分です。

Linearへ任せやすいのは、仕事の投影、ロードマップ、進捗表示、チーム計画の画面です。

一方で、どの情報を正本とするか、どの判断権限がどこにあるか、何を証拠として受け入れるか、といった意味まで一つの画面へ閉じ込める必要はありません。

Linearは、強力な計画・可視化の表面として利用しつつ、仕事の意味を別の正本へ残すことができます。

GitHub Projects — IssueとPull Requestを投影する作業ビューとして近い

GitHub Projectsは、Issue、Pull Request、アイデアを表・ボード・ロードマップとして表示し、独自フィールドやグラフで整理できます。

AI-WGで仕事の関係や現在状態を見渡す考え方と、見た目が近くなる部分があります。

ただし、GitHub Projectsは柔軟な作業管理画面です。

Issue / Pull Request
  = 実際の仕事と変更を持つ場所

Project
  = それらを見渡しやすくする投影

という使い分けもできます。

Projectの画面を使うことと、そこを仕事の意味の唯一の正本にすることは同じではありません。

GitHub Spec Kit — かなり近いが、中心に置く範囲が違う

Spec Kitは、仕様を先に構造化し、計画、作業分解、実装へ進めるSpec-Driven Developmentのためのツール群です。現在は複数のAI coding agentとの連携や、繰り返し可能なワークフローも提供しています。

共通する考え方があります。

• その場限りの依頼だけで進めない
• 意図を先に構造化する
• 作業成果を次の段階へ引き渡す
• AIへ構造化された文脈を渡す
• 手順を再利用する

そのため、Spec Kitを「まったく別物」と扱うのは不正確です。

違いを見るなら、AI-WGでは一つの開発手順だけでなく、複数の作業項目、正本、権限、判断履歴、証拠、別のAIへの引き継ぎまで長く持続させることを重視します。

Spec Kitは競合と決めつけるより、仕様駆動の開発手順を借りたり接続したりできる隣接領域と考える方が自然です。

Backstage — 「何があり、誰が持つか」の地図として近い

Backstage Software Catalogは、サービス、Webサイト、ライブラリ、データパイプラインなどのソフトウェア要素と、その所有情報・メタデータを中央で把握する仕組みです。

AI-WGでも、

• 何が存在するか
• 誰が責任を持つか
• 何と関係しているか

を明示する必要があります。

この部分はよく似ています。

ただしBackstageの中心は、ソフトウェア資産を発見・整理するカタログや開発者向けポータルです。

AI-WGでさらに扱いたいのは、個々の仕事について、

何を正しい情報として扱うか
誰が変更を決めてよいか
どの証拠で状態を変えてよいか

という判断の意味です。

LangGraph — AIワークフローを実行する仕組みとして近い

LangGraphは、長時間動く状態保持型のAIエージェントやワークフローを構築するための、低レベルなオーケストレーション基盤・実行環境です。

長時間実行、状態保持、人間の介入といった機能は、AI-WGで扱う「仕事を途中で失わず続ける」という問題と接点があります。

ただし責務は分けられます。

LangGraph
  = ワークフローをどう実行するか

AI-WG
  = そのワークフローが何の仕事で
    何を正本とし
    どの権限で
    何を証拠として受け入れるか

LangGraphを実行基盤として採用しても、仕事の意味まで内部状態だけへ閉じ込める必要はありません。

実行方法をLangGraphへ任せ、仕事の意味は外部に残すという組み合わせが可能です。

OpenHands — コードを扱うAI実行役として近い

OpenHands Software Agent SDKは、コード、ファイル、システムコマンドなどを扱うソフトウェア開発エージェントを構築・実行するためのSDKです。CLIやクラウドの実行面も提供されています。

ここでは主に、実際にコードを調べ、変更し、道具を使うAI実行役として比較できます。

OpenHands / Claude Code / Codex
  = 実行する

AI-WG
  = 何を、どこまで、どの権限で進め、
    何をもって成立とするかを外へ残す

実行できる能力があることと、その仕事を受け入れてよい権限があることは別です。

AI-WGは特定のコーディング実行役を置き換えるより、実行役が変わっても仕事の意味を持ち越せる状態を重視します。

Obsidian — 知識を保存・接続する基盤として近い

ObsidianはVault内のノートやファイルを扱い、Markdownを編集し、ノートを検索・接続できる知識作業の基盤です。

AI-WGでも、長く残す設計、判断、手順、履歴をファイルとして管理する構成は有効です。

ただし、ファイルを保存できることだけで、

• 何が正本か
• 誰が変更してよいか
• 何を確認すれば成立するか

までは自動的に決まりません。

Obsidian / Markdown
  = 保存・閲覧・接続の基盤

AI-WG
  = 保存された情報へ責務と判断境界を与える考え方

と分けると理解しやすくなります。

GitHub Issues / Pull Requests — 最も重要な基盤の一つ

GitHub Issuesは仕事を計画・議論・追跡するための場所、Pull Requestはリポジトリ変更を提案・レビュー・mergeするための場所です。

AI-WGではこれらを継続可能な作業記録として活用できます。

しかし、IssueとPull Requestを使うだけで、

• 何を正本とするか
• 誰が何を決めてよいか
• 別のAIへどう引き継ぐか
• 何を証拠として完了を判断するか

が自動的に決まるわけではありません。

GitHubを置き換えるのではなく、GitHub上の作業記録へ責務を割り当て、別の実行役や知識基盤と接続するという使い方ができます。

比較表

この表は「どちらが優れているか」を決めるためのものではありません。

どの責務を外部へ任せられるかを見るための表です。

「全部入り」を目指さない

既存製品と比較すると、似た機能をすべて自前で実装したくなります。

しかし、それでは維持するものが増え続けます。

flowchart LR
    accTitle: 外部ツールへ責務を任せる判断
    accDescr: 必要な責務を外部ツールへ安全に任せられるかを判断し、任せられる場合は接続し、任せられない場合は最小限の責任主体を残す。
    N[必要な責務] --> Q{外部ツールへ安全に任せられる?}
    Q -- はい --> E[借りる / 接続する]
    Q -- いいえ --> S[最小限の責任主体を残す]
    E --> R[意味 / 権限 / 証拠の境界だけ保持]

• 計画画面が必要ならLinearやGitHub Projectsを使う
• ワークフロー実行が必要ならLangGraphを検討する
• コーディング実行役が必要ならOpenHands、Claude Code、Codexなどを使う
• ソフトウェアカタログが必要ならBackstageを使う
• 知識を保存・接続するならObsidianを使う

そのうえで、

外部ツールを交換しても失いたくない仕事の意味だけを残す。

という考え方です。

まとめ

既存ツールとの比較で一番避けたいのは、「同じ機能があるから同じシステム」と考えることです。

似た能力があるか
      ↓
同じ責務を持つか
      ↓
置き換えられるか

AI Work Governanceの価値を、「既存製品にない機能の数」で定義する必要はありません。

むしろ、

外部ツールへ機能を任せても、人間の意図、正本、権限、証拠、判断履歴、作業項目のつながりを持続できるか。

そこが比較の中心です。

参考資料

• Linear Docs — Initiatives
• GitHub Docs — Planning and tracking with Projects
• GitHub — Spec Kit
• Backstage Docs — Software Catalog
• LangGraph Docs — Overview
• OpenHands Docs — Software Agent SDK
• Obsidian Help — Obsidian URI