第7回：Github SpeckitがIBM Bobにも対応したので動かしてみる

はじめに

IBM BobはGithub Speckitに対応しているので、動作確認をします。

Github Speckit概要

Github Speckitは、Githubが提供する仕様駆動開発（SDD）を支援するオープンソースのツールキットです。
AWSのKiroとならんで有名なSDD支援ツールです。KiroはIDEですが、こちらはカスタムコマンドベースのツールキットで、様々なエージェントツール（Github CopilotやClaude Codeなど）上で同じ操作で使えます。

Speckit公式のREADMEを見ると、確かに「IBM Bob」が追加されています。

Specifyのインストール

Speckitは「Specify」というツールを先にインストールします。
uvというパッケージマネージャーが必要です。インストールは公式サイトを参照してください。

プロジェクトフォルダにSpeckitを導入

インストールしたSpecifyを使って、プロジェクトにSpeckitのツールを入れます。
対象の開発プロジェクトフォルダで以下を実行します。

実行すると、プロジェクトフォルダに.bob/commandフォルダと.specifyフォルダが追加されます。

.bob/commands以下がBon用のスラッシュコマンドです。

Bob（IDE）のチャット欄で/speckitと入力すると、コマンドが候補表示されます。

同じプロジェクトで、Claude Codeなどの他のAIエージェントも併用したい場合は、エージェント毎に初期化コマンド実行することで利用できます。

Speckitの使い方

各スラッシュコマンド（/speckit.xxxxx）を、チャット欄で順に実行していきます。引数で詳細を記入します。
スクラム開発のような感じで、作成機能ごとに設計→実装を繰り返す形です。

1.: /speckit.specify → スペック（spec.md）を作成（作成する対象のWhat, Whiの定義）

2.: /speckit.plan → 技術設計（plan.md）の作成（specの実現方法(How)。利用技術や非機能系など）

3.: /speckit.tasks → spec, Planから具体的な実装タスクリストを生成

4.: /speckit.implement → タスクリスト順に、spec,Planを実装＆テスト。TDDアプローチ

プロンプトで「spec1～2をまとめたタスクリストを作る」「とりあえずタスク1～3までを実装」といった指示が可能です。

また、生成系のコマンド以外には以下があります。

/speckit.constitution → プロジェクト全体の原則定義（Speckit用のAGENTS.mdのようなもの。.specify/memory/constitution.mdを更新）
/speckit.clarify → specの曖昧さの解消（AIがspecを見て質問をしてくる。）
/speckit.checklist → specとPlanから品質検証チェックリスト生成
/speckit.analyze → spec, Plan, Taskの内容の整合（一貫性）分析
/speckit.taskstoIssues → GitHub連携（オプション）

/speckit.clarifyは、生成AIがspecを呼んで規定数の質問をしてくるというものです。
感覚としては、実装者が設計担当に質問してくるQ&Aのような感じで、設計の考慮漏れ、または（AIがやってしまいがちな）オーバースペック実装を未然に防ぐのに有用と思います。

Speckitを使う時の注意

日本語化

AGENTS.md（またはconstitution.md）で、日本語を使うことを記述する。
Spec/Plan/Taskのドキュメントテンプレート（.specify/templates/）が英語なので日本語化する。

中間生成物（コンテキスト）が多いので、1つのspecの実装が終わるまでにかかるAIコストが高くなるため、コストを減らす工夫が必要

プロンプトを簡潔、かつ箇条書きにする。
specを膨らませない指示の書き方をする。（Why, What, Acceptance, 制約。テンプレート最適化も有効）

1つのspecの実装範囲を小さくする。（他のspecと干渉しない）
1つのspec内のユーザーストーリーや、エッジケースに上限を設ける。
軽微な仕様変更なら、specを作らず、planだけ作って実装にまわす。
毎回別チャット（BoBの場合別タスク）で指示をだして、コンテキストウィンドウを空にする。

各コマンド実行時に、gitコマンドが実行されている。（気づかないので注意）

init時にgit initがされている。
/speckit.specifyの内部で、git branchが実行されてローカルブランチが作られる。
- 「番号-spec名」という名前のローカルブランチが造られる。
- 既存コードの改修の場合は「feature/番号-spec名」のブランチが作られる。
コミット/マージ忘れ/平行開発で注意

ドメインロジックや画面設計はspecに直書きせず、別ファイルを参照する形がいい。

docs/domain/xxxx-rules.mdなどの別ドキュメントにする。
/speckit.specify実行時に参照する
- コンテキストが増えやすいので分割が必要
画面はspecをレイアウト単位でなく、ふるまい単位で分ける。（小さすぎる気もするが）
- spec001- 〇〇画面基本レイアウト
- spec002- 〇〇画面（検索機能）
- spec002- 〇〇画面（登録機能）

まとめ

以上、エンタープライズレベルでの導入を想定したGithub SpeckitをIBM Bobでも利用できました。SDDに関してはIBMは独自のアセットを開発しているとのことで、公開が待たれます。
但し、受託開発で顧客との要求仕様合意をすべてSDDで行うのはオーバヘッドが大きすぎます。SDDの目的は「AIが正しい実装をするため」のものであるため、要求定義後、基本設計から開始するなどプロジェクトでの使いどころを押さえておくべきです。

おまけ：SpeckitのIoC（Infrastructure-as-Code）版

実験用ですが、IBMがTerraformのIoC向けのカスタムSpeckitを公開しています。
IBM/ibm-spec-kit
Bobでも利用可能のようです。
IoCでのシフトレフト（実装でなく設計で品質を上げる）がどこまで有効なのかは不明ですが、紹介まで。

※ 記載の製品名及び社名は各社の商標もしくは登録商標です。
※ IBM、ibm.comは、米国やその他の国におけるInternational Business Machines Corporationの商標または登録商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、ibm.com/trademarkをご覧ください。

執筆者：
IBM Bob検証コミュニティ（基盤システム本部　モダナイゼーション部　代表編集）

前話へ

連載コラム：IBM BobでAIエージェント開発を試してみた

エクサでは、様々なAIエージェントを検証していますが、セキュリティや規制が厳しいエンタープライズの基幹システム構築やレガシーモダナイゼーションにも適用可能な選択肢として、間もなく正式版が公開されるIBM Bobの活用も視野に入れています。
公開に先立ち、アーリーアクセス版を試用しましたので、その過程を共有します。