MENU

IBM Bobを活用するためのステップ ~事前知識・設定・基本操作 ❷使い始める前に知っておくべきこと |特集 IBM Bob Part3

Pro、Pro+、Ultra
導入の前提条件

次にBobの利用に必要な前提条件をまとめておこう。今回はPro、Pro+およびUltraを利用する際の条件をまとめる。エンタープライズ版の前提については、共通事項を除いて本稿では触れない。

Bobを利用するには、無料プランの利用を含めてIBMidが必要になる。Bobをダウンロードしてセットアップ後、起動して利用を開始する際に要求されるが、Googleアカウントでサインアップすることも可能だ。使用する際は画面の指示に従って登録しておこう。

Bobコインと
消費量の確認方法について

BobのAI機能は、プランごとに事前に割り当てられた「Bobコイン(Bobcoin)」を消費することで利用可能になる。使用状況については、Bob固有設定(Bobのチャット画面右上の設定アイコンをクリックすることで表示されるタブ)の「使用状況」から上限・使用済み・残り%をいつでも確認できる(図表6)。

図表6 5種類のモードが用意されている

Bobコインは、解析および作成するソースコードのステップ数ではなく、コンテキストのサイズに応じて消費される。もちろんコンテキストをどれぐらい消費するかは、モードや作業内容によって異なるので注意が必要だ。

現在のタスク(会話)で消費しているコンテキストのサイズとBobコインは、会話ウィンドウの右上に表示されるので、常に参照するクセをつけるとよい(図表7)。

図表7 現在の会話で消費しているコンテキストのサイズとBobコインの確認

この例では、コンテキストウィンドウ 200k のうち 28k を消費しており、0.30Bobコインをこのタスクで消費したことを示している。

プランごとの月次コイン付与量は以下の通りである(図表8)。

図表8 プランごとの月次のBobコイン付与量

コインは毎月の請求サイクル開始時にリセットされ、翌月への繰り越しはない。また請求サイクル内でBobコインを使い切ったとしても、コインの追加購入は現時点で行えず、使い続ける場合はプランのアップグレードが必要だ。Enterpriseプランのみ、1000コイン単位のパック購入が可能(購入から1年で失効)で、かつ組織内のユーザーに購入コインを割り振ることができるので、企業ユーザーはEnterprise利用を検討するのがよいと思う。

IBM i開発利用時の注意点 

現時点でBobは、IBM iのソースメンバーに直接アクセスする機能を標準で持っていない。現実的な解決策は、ソースメンバーをローカルにダウンロードしてBobで解析することである。

これを実現するには、Code for IBM iなどの拡張ツールを使えばよい。詳細については拙稿「Code for IBM i:その全貌 ~IBM i開発をオープンへと進展させるオープンソースの開発環境」(i Magazineサイトに掲載中)を参照してほしい。

ソースメンバーがリモートにある場合とローカルにある場合の違いを考えてみよう(図表9)。

図表9 シナリオAとシナリオB

シナリオAのBobとLLMとの間の「×」 は、「Code for IBM i経由で直接参照したソースファイルのメンバーは、コンテキストに含めることができない」ことを意味する。実際、Code for IBM i拡張機能でIBM i上のソースを明示的にプロンプトに「@」付きで指定することはできるが、そのプロンプトを実行するとIBM iのソースではなく、ローカルのファイルを探しに行ってしまった。

シナリオB(ソースをローカルにダウンロードしてから渡す)であれば、AIモデルへ確実にソースコードを渡せる。ローカル管理にできればgitによるバージョン管理も可能になるので、ぜひシナリオBへの移行を検討してほしい。

使い始める前のセキュリティ設定 

企業がBobを導入する際、セキュリティについてもきちんと理解することが重要である。自社のセキュリティ・コンプライアンスに則ってBobを利用できるかどうかは、各社で必ず確認してほしい。特にAIモデル改善のためにプロンプトやソースコードが学習データとして利用されるかどうかは、最初に確認するべきだ。

ここでは、Bobの使用者個人が注意すべきセキュリティ設定について解説しておきたい。

先ほども触れたように、Bobはローカルにあるディレクトリおよびファイルを操作することができる。通常使用では、Bobが開いているディレクトリ内が操作対象となるので、その中の情報をどのように保護するかが重要となる。誤って大事なファイルを削除したり、予期せぬコマンドで機密情報をBobに送信したりすることがないようにしなければならない。

まずBobを使い始めてしばらくは、自動承認を「無効」の状態で使ってほしい。この状態であればBobが何か操作をするたびにユーザーに承認を求めてくる。

たとえば、ファイルを読むタイミングや、作成したファイルを保存するタイミングなどで、その操作を続行させるかどうかを「承認」か「拒否」ボタンで制御できるようになる。

各処理のたびにこのアクションが起きるのは面倒と感じるかもしれないが、どのモードでどんなプロンプトを入力すればよいか、入力の違いによってBobは何をするのかを理解できるので、最初はこの状態で作業することをお勧めする(図表10)。

図表10 自動承認を無効にする

次に、意図的にBobに渡したくないファイルやディレクトリがあれば、それを事前に登録できる「.bobignoreファイル」を使うとよい。

.bobignoreファイルは、Bobが処理しているディレクトリのルートに存在している必要がある。手動で作成してもよいが、Bobのエクスプローラ上で対象とするディレクトリやファイルを右クリックすると表示される「.bobignoreに追加」を選択すると、.bobignoreファイルが存在しない場合は作成してくれる(図表11)。

図表11 「 .bobignoreに追加」を使用する

コンテキスト設計
設定なしと設定ありの違い 

最初にBobを使うとき、たとえば図表12のように利用することが多いと思う。

図表12 「このプログラムを説明してください。」

図表12のプロンプトは、Askモードで「このプログラムを説明してください」と指示している。Bobはこれだけでも自然言語で解説文を返してくれるが、出力内容や形式は同じプロンプトを指定しても、実行するたびに回答は異なるだろう。

そこでBobに「ルール」と「文脈」を与えることで、出力の質をある程度制御できる。これを実現するには「AGENTS.md」を活用する。

まず、プロジェクト全体のルールを指定するためのAGENTS.mdをプロジェクトのルートに作成する。このファイルの内容は、常にコンテキストに読み込まれる。AGENTS.mdが肥大化してきたときは、目的別に分割して.bob/rules/に置くことができる。

また、各モードを選択するたびにコンテキストに含めたいルールがあれば、.bob/rules-{モード名}/に固有のルールを指定したファイルに追記できる(図表13)。

図表13 .bob/rules-{モード名}/ で追記する

各モードには、Bobがあらかじめ英語で定義したルールが存在する。その内容は、Bobの設定画面の「モード」をクリックすると表示される各モードを選択することで確認可能である(図表14はモードをクリックした場合の画面、図表15はAskモードであらかじめ指定されている内容)。

 

図表14 IBM Bobに事前に定義されているルールの確認
図表15 定義されているルールの内容

.bob/rules-{モード名}/ に追加するファイルはその補足として機能するため、事前定義と重複しない内容を記述することがポイントである。

これらのファイルはプロジェクト内に置かれるため、gitで管理すればチーム全体で共有できる。Bobの振る舞いをチームで統一でき、成果物の一貫性を保てるようになる。

AGENTS.md およびモードごとのルールファイルは手動で作成してもよいが、/initコマンドを使うと現行のディレクトリ内のファイルをBobが自動スキャンして生成してくれる。方法は簡単で、Codeモードに切り替えてチャットに/initと入力するだけだ。

実行すると図表16のファイルが生成される(図表17は実際に生成されたファイル)。

図表16 /initで生成されるファイル
図表17 /initで生成されたファイル

生成後は内容を確認し、ビジネスルールやチーム固有のプラクティスなどBobが自動では把握できない情報を手動で追記しておくとよい。プロジェクト構造や技術スタックが大きく変わったときは、/initを再実行して最新の状態に保つことを推奨する。

ルールファイルは「育てる」もの

「インストールしてすぐ使える」という認識でいると、Bobから期待通りの出力は得られない。AGENTS.mdや各ルールファイルをどう設計し育てるかが、Bobに限らずAIツール活用の成否を決めると言っても過言ではない。

Bobを使いながら「この指示では意図通りに動かない」ことを見つけ、これらのファイルを適切に修正・追記して精度を上げていくサイクルが必要だ。これは従来の開発でいう「設計書・コーディング規約の整備」と本質的に同じである。IBM i開発者がこれまで培ってきた「いかに仕様を正確に言語化するか」という能力を、そのまま活かせる領域でもある。

ルールファイルの記述例
「知識」と「ルール」は分けて管理

図表18は、IBM i開発プロジェクトでのルールファイルの記述例である。「全モードで必要な知識」と「コード生成時だけ必要なルール」を分けて管理することがポイントだ。

図表18 ルールファイルの記述例

ルールファイルの記述量については公式に規定はないが、ルールファイルは毎回コンテキストに読み込まれるためBobコインを消費する。

AGENTS.mdは50〜100行、モード別ファイルは30〜50行を目安に簡潔にまとめるとよい。「なぜそのルールが必要か」の背景説明は不要で、指示だけを箇条書きで書くこと、同じ内容を複数のファイルに重複して書かないことが重要だ。

1点注意しなければならないのは、上記ファイルで指定された「ルール」は常に厳密に守られるものではないということだ。これらのファイルはBobに渡すコンテキストに含めることは保証されるが、それをAIモデルがどう扱うかは、また別の問題だからである。おおよそ従ってくれるルールという位置づけで理解しておく必要があるだろう。

著者|
小川 誠

ティアンドトラスト株式会社
代表取締役社長 CIO  CTO

1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。

——————————

Part3 IBM Bobを活用するためのステップ ~事前知識・設定・基本操作 

❶IBM Bobを使うために知っておくべきこと
❷使い始める前に知っておくべきこと
❸現場での活用と注意点
❹AI時代における開発プロセスの変化

——————————

[i Magazine 2026 Summer掲載]