【Copilot】AI駆動開発では役割を分けて、トークン節約をする【IBM Bob】

IBM Bobで出力した内容、Copilotへのプロンプトを含みます。

生成AIを利用する上で、意外と気にされないことが「トークンの節約」です。

AI駆動開発において実際の開発に取り組むと、やり取りしているだけでトークンを消費し、結果的に 「開発のためのトークンがない」 ということがしばしばあります。

必然的に、開発が進まないことやコスト増についてのやり取りが発生します。
それらはわずらわしく、流れを絶ってしまうストッパーです。

この記事では、企業・個人でも生成AIを複数利用するのが当たり前になっている状況をもとに、役割りを分けることを案内します。

・Copilotに 「仮の」 要件定義、仕様書の作成を任せる
・IBM Bobで要件定義、仕様書を 「精査」 する
・Copilotに 確定版 を作成させる
・IBM Bobで 開発 を行う

本当に必要なところにトークンを割くように、役割分担をさせましょう。

Copilotに仮で書かせ、IBM Bobで精査する理由

IBM Bobで精査する理由を明確にします。大きく3つの強みを挙げます。

• 実装との整合性検証 - 仕様と実態の乖離を検出
• 大規模コンテキスト - 全体像を保持した分析
• プロジェクト固有の理解 - 汎用的でなく具体的な指摘

特に大規模なコンテキストの部分を参照してもらうのが大事です。全体像を保持した分析は、要件定義から発生した仕様書が、複数ファイルになっていても、それらを保持したまま分析できるからです。

下記は一例です。

プロジェクト構成

├── 01_要件定義.md (20KB)
├── 02_機能仕様.md (30KB)
├── 03_API仕様.md (25KB)
├── 04_DB設計.md (15KB)
└── 05_セキュリティ仕様.md (10KB)
合計: 100KB → 200Kトークン以内で全体把握可能
（日本語: 約10万文字程度）

プロジェクト構成内部のmdファイルをCopilotに記述してもらい、IBM Bobで分析する。そのフィードバックは実装との整合性や、具体的な指摘として返されます。

このフィードバックループをするだけで、トークンを節約しながら高品質な実装に繋げることができるということです。

要『件』定義ではなく、要『求』定義から始める

ある程度固まっている要件でも、Copilotと最初の壁打ちをする際には、要求がなんであるか？を明確に指示することが、精緻な定義に役立ちます。要求がはっきりしていれば、その後に不足している項目をあらい出せるからです。

合わせて、要求で不足しているところも聞いてしましましょう。

要求定義プロンプトの例

最終目的：新しいシステムの要件定義、仕様書をmdファイルで作成してもらいます。

まずは、要求されている定義を下記に記載します。
要件定義に落とし込む際に不足している点、質問点を洗い出してください。

・Linuxに搭載する
・Webアプリケーションの作成
・チームで利用するチケット管理システム
・定期的な業務はあらかじめ作成した定期チケット発行
・チケットの発生は、Slackやメール、別途連絡が入るたびに増えていく
・似たような業務は画面からワンクリックで選択して、詳細はテキストにnoteとして残しておく
・期限を設定できるようにする
・優先度の設定をしなくちゃいけない
・問い合わせ先を定義することで、誰かに続きを渡すことができるようにする
・フェーズで管理して、完了すると終了にしたい

Copilotの回答（一部）

1. システム全体・前提条件に関する不足点／質問
運用環境

Linuxのディストリビューション指定は必要か（例：Ubuntu / Amazon Linux / RHEL等）
オンプレミス or クラウド（AWS/GCP/Azure等）のどちらか
将来的なスケール（ユーザー数・チケット数）想定
本番／検証／開発環境の環境分離は必要か

利用者

想定ユーザー数（同時接続数含む）
利用者の**役割（一般ユーザー／管理者／閲覧のみ等）**は存在するか
チームは1チームのみ or 複数チームを想定するか


2. 認証・権限まわりの不明点

ログイン方式

ID/パスワード
Slack連携ログイン（SSO）
社内認証基盤（LDAP / Azure AD 等）


権限管理は必要か

チケット作成可能／閲覧のみ
管理者専用機能（定期チケット設定など）


チケットの参照制限（自分のチームのみなど）はあるか

このように、まずはCopilotに対して、概要的な要求を渡して、不足している内容を洗い出してもらいます。これだけでも考えることは多く、要件定義が大変ということが見えてきますね。

仮状態の要件定義を「IBM Bob」に見てもらう

先ほどの要求をもとに、Copilotに草案としてmdファイル形式で出力してもらいました。その内容をIBM Bobに精査してもらいます。

出てきたレポートの一部を抜粋します。

IBM Bobのレポート

MVP要件定義として構造は良好ですが、以下の観点で改善が必要です：

🔴 Critical: 2件（セキュリティ、データ整合性）
🟡 High: 5件（技術仕様、運用設計）
🟢 Medium: 3件（ユーザビリティ、拡張性）
🔴 Critical Issues（即座に対応必要）

1. 認証・認可の仕様が未定義
問題点:

「一般ユーザー」「管理者」の定義はあるが、
ログイン方法、セッション管理、パスワードポリシーが不明

リスク:

不正アクセスの可能性
なりすましによるチケット改ざん
監査証跡の欠如


~~~
長いので割愛
~~~


追加推奨項目
データベース設計の明示
### 19. データモデル（概要）

#### テーブル構成
- users（ユーザー）
- tickets（チケット）
- recurring_tickets（定期チケット設定）
- ticket_templates（テンプレート）

#### ER図
[Mermaid ERD を追加]

改善後の構成案
# チケット管理システム 要件定義書（MVP版）

## 1. 目的
## 2. システム概要
## 3. 想定利用環境
## 4. 技術スタック ← 追加
## 5. 認証・セキュリティ ← 追加
## 6. ユーザー定義
## 7. チケット管理機能
## 8. データ整合性 ← 追加
## 9. 定期チケット機能
## 10. 業務テンプレート機能
## 11. 画面設計 ← 拡充
## 12. 非機能要件 ← 追加
## 13. エラーハンドリング ← 追加
## 14. バックアップ・運用 ← 追加
## 15. 用語集 ← 追加
## 16. データモデル ← 追加
## 17. 受け入れ基準 ← 追加
## 18. MVP範囲外
## 19. ゴール

Askモードで実行。草案段階で、多くのレポートを出してくれます。一度これを持ち帰り、Copilotと壁打ちしつつ、要件定義に落とし込んでいくことで、多くの問題を事前に解決しながら、要件定義書、仕様書を正確に作成することができます。

Mermaidクラス図で構造表現、Mermaidマインドマップでの表現

仕様書に落とし込む際にも、下記のような図で表現されるので、mdファイルでの文字的な表現だけではなく、視覚的に分かりやすいところに落ち着けることができます。

Mermaidクラス図

Mermaidマインドマップ

トークン節約の書類作成。次回に続く

今回は、シンプルな要求定義をしてから、Copilotに草案を出してもらいました。

次は、Copilotで精査して、再度IBM Bobで読み込ませることで、どのように進むのかということです。最終的に１回のフィードバックで済むのであれば、トークンの利用を格段に減らすことができます。

この図の、下を目指し、どの程度の精度に落ち着くのかをご紹介していきます。

多くの生成AIがあるため、もちろん要件定義がChatGPTの場合もあるでしょう。今回はCopilotでの草案と、IBM Bobの一例をお見せしています。

命題はあくまでトークン節約のための役割分担です。CopilotとIBM Bobの有利な部分をしっかりと分けることで、今後の要件定義と仕様書の業務はより効率的かつ、リスクの少ないものに変化していくでしょう。

効率化を図る記事、節約の参考文献

今回は効率的にBobを活用している記事についてご紹介いたします。
引用した記事の名前と、著者、URL、その概要について、記載しています。

ご参考にしてください。

IBM Bob カスタム・スキル 開発："pptx-generator" で PowerPoint 生成

著者: @c_u 様
URL: https://qiita.com/c_u/items/3725a6df720664ebdca2
概要: Bobのカスタムskill機能によって、軽量なパワーポイント作成が可能になります。ゼロベースで作成する手間も省けるほか、bobcoinsの消費も少量で済むことを紹介。実際にどれくらいのトークン消費量（bobcoins換算）なのかも掲載しています。