これはBobブログの最初の投稿です。Bobを構築しているチームが、それを使用する開発者のために書いています。エンジニアリングの決定を説明し、実際のコードベース内でAI開発パートナーを提供する中で学んだことを共有し、時には立場を主張するために使用します。これはドキュメントでもマーケティングでもありません。どちらかが必要な場合は、適切な場所にリンクします。

最初の投稿では、Bobが行うすべてのことを説明するのではなく、3つのことを行いたいと思います：

Bobのコア機能のいくつかを見る。
Bobが最高の仕事をするためにリポジトリを設定するための実用的なヒントを共有する。
コードへのこの種のアクセス権を持つツールでセキュリティにどのようにアプローチするかを説明する。

1. 開発者が実際に時間を費やしていること

最新のAIアシスタントは、説明から関数を書くことができます。これはしばらく前から真実であり、もはや興味深い質問ではありません。興味深い質問は、作業が「新しいコードを生成する」ではなく「既に存在するシステムを変更する」場合に何が起こるかです。変更を行う適切な場所を見つけ、チームが合意した規約を理解し、何年も成長してきたファイル全体で動作を一貫させることです。これがプロフェッショナルなソフトウェア開発のほとんどの姿です。Bobはこの種の作業のために構築されており、この投稿の残りの部分で説明する設計上の選択は、この焦点から生まれています。

1.1. モード：Bobに行っている作業の種類を伝える

Bobは単一の「何か便利なことをする」インタラクションではありません。セッションを開始するモードは、これから行う作業の種類、到達できるツール、どれだけ積極的であるべきかをBobに伝えます。

Ask — 読み取り専用。「探索フェーズ」に最適です。Bobは変更を加えずにアーキテクチャとロジックを説明します。レガシーシステムに飛び込むとき、または自分が書いていないロジックの健全性チェックを実行するときに使用します。
Plan — Bobは、これから行う変更の計画を作成します：触れるファイル、考慮すべきエッジケース、推奨される作業順序。出力は計画であり、コードではありません。
Code — 実際に変更を行うため。Bobは、設定した規約とルールに従って、プロジェクト内で読み取り、書き込み、テストを行います。
Advanced — Model Context Protocol（MCP）を通じてCodeモードを拡張し、Bobに組織固有のツールとサービスへのアクセスを提供します：内部API、データベース、独自のツール。
Orchestrator — モードをまたぐ複数ステップの作業用。Bobは、現在のステップが必要とするものに基づいて、モード間を自動的に切り替えます。探索、計画、実行を組み合わせた大規模な作業に適した選択です。

セッションの開始時に適切なモードを選択することは、より良い出力を得るために利用できる最も安価なレバーの1つです。特によく知らないコードベースや、実際の表面積を持つ変更の場合、良い習慣はAskまたはPlanで開始し、作業の明確なイメージができたらCodeに切り替えることです。Codeに直接行く方が瞬間的には速く感じますが、そこで仮定が実際の変更として滑り込み、技術的負債として蓄積し始める傾向があります。

1.2. Bob tips：リアルタイムの複雑性メトリクス

誰もが経験したことがあります：「ゾーン」に深く入り込み、エッジケースを処理するために最後の条件をネストし、突然、単一の関数が30行の迷路に成長しています。典型的なワークフローでは、その迷路は、チームメイトが数時間後にプルリクエストで指摘するまで解きほぐされません。Bob Tipsは、ロジックがまだ頭の中で温かいうちにリファクタリング提案を提供することで、物語を変えます。入力すると、継続的な静的解析が静かにオープンファイルを監視します。関数が高い循環的複雑性の境界を越えたり、保守が困難になったりすると、Bobはすぐに紫色の下線でフラグを立てます。従来のリンターは、何か間違ったことをしたことを伝えるだけです。Bob Tipsは脱出方法を提供します。ツールの焦点は、実行可能なリファクタリング提案を提供することに完全に置かれています：

コンテキストインテリジェンス：紫色の下線にカーソルを合わせると、警告が表示されるだけでなく、その場でロジックを解きほぐすための特定のAI生成戦略が提供されます。シームレスな実行：Fix with Bobをクリックすると、専用のチャットが即座に開きます。AIはすでに関数のコンテキストを保持しており、あなたと一緒にクリーンアップを実行する準備ができています。

バックグラウンドで実行されているメトリクスは、単なる配管です。価値のある部分は、長年のコード品質シグナルが、3日後のコードレビューで表面化するのではなく、開発者がファイルにいる瞬間にAI提案を駆動することです。

1.3. Reviewモード：システムが一緒に読むコードレビュー

コードレビューは、過去20年間でソフトウェア品質のためにどの実践と同じくらい多くのことを行ってきましたが、チームが勢いを失う場所でもあります。Bobは人間のレビューを置き換えません。機械的な部分を行うので、「簡単な」バグを探すのではなく、高レベルのアーキテクチャと意図に集中できます。

レビューは、サイドバーのReview Panelまたはチャットの/reviewから実行されます。2つのモードがあります：

ブランチ比較。 このモードは「クラシック」diffを処理します。/reviewを使用して、現在のheadに対してコミットされていない作業を監査するか、/review <branch>を使用して特定のリモートをターゲットにします。通常、レビュースレッドを詰まらせる「nitpicks」に対する先制攻撃です。
Issue カバレッジ。 /review <issue-url> --issue-coverageは、ローカルの変更がGitHub issueが求めるものに実際に対処しているかどうかを検証します。これは、開発者が試すまで欲しいとは気づかなかったと私たちに言うモードです。結果は専用パネルに表示されるため、レビューしてBobで修正することを決定できます。良いコードを書いただけでなく、正しいコードを書いたことを確認する健全性チェックです。

1.4. Literate coding：コードの隣に書かれた意図

複雑な機能に深く入り込んでいるとき、チャットウィンドウで複数のファイルを参照するのは面倒です。「types.tsのインターフェースとapi.tsのサービスを見て、ここでロジックを更新して...」と入力していることに気づきます。Bobはこのダイナミクスをひっくり返します。Literate Codingを通じてインタラクションをソースファイルに直接移動することで、エディター自体がインターフェースになります。これは、サイドパネルを避けることだけではありません。AIに意図の洗練されたマルチファイルマップを提供することです。

意図を自然に表現：Cmd+Mでモードを切り替え、プレーンな言語または疑似コードでロジックを書きます。指示はエディターに青色で表示され、実装が属する場所に正確に存在します。
単一行を超えて：従来のチャットは複雑なプロジェクトの「スレッド」を失うことがよくありますが、BobのLiterate Codingはファイル間のギャップを埋めるために進化しています。開発者は複数のモジュール間でコンテキストを提供できるようになり、データモデルの変更が関連するコントローラーに正確に反映されるようにします。
即座の検証：Cmd+Enterを押すと、Bobはその場で実装を生成します。結果はインラインdiffとして表示されるため、変更にコミットする前に、周囲のコードに対してロジックを監査できます。

利点は簡単です：プロンプトはコードが存在する場所に存在し、周囲のファイルがすでにコンテキストとして機能しています。現在のスコープは単一ファイルです。マルチファイルサポートはロードマップにあります。

1.5. ターミナルのBob

Bob Shellは、Bobの機能をコマンドラインにもたらします。特に価値があると思われる2つの使用方法があります。

ワークスペースとしてのターミナル：シェル内でAI開発アシスタントと作業することは、それ自体で人気のあるフォームファクターとして登場しました。多くの開発者がすでにGit、ビルド、テストを駆動する方法と自然にペアになり、多くのチームの日常のワークフローの一部になっています。ネイティブIDE統合が利用できないリモートサーバーや環境にAIをもたらす最も信頼できる方法です：ターミナルがあればどこでも、Bobを持つことができます。
決定論的から適応的自動化へ：Bob Shellは、スケジュールされたジョブやCI/CDパイプラインのデプロイメントスクリプトなどの非対話型セッションで輝きます。今日、スクリプトが決定論的ツールにシェルアウトする場所では、周囲のリポジトリの完全なコンテキストを持つBobにシェルアウトできます。そして、反対側から出てくる自動化は、固定パイプラインよりも適応的です。

CIで非対話的にBobを実行することから学んだことについて、フォローアップ投稿を公開します：PRサマリー、リスクフラグ付け、既存の自動化への統合など、実際にうまく機能するパターンです。

2. リポジトリをBob対応にする

Bobが最高の仕事を生み出すリポジトリは、いくつかの共通の特性を共有しています。それらのどれもAI固有ではありません。どの開発者にとってもリポジトリを快適に作業できるようにするのと同じものですが、それぞれがBobに作業するためのより多くのものを与えます。

高速で信頼性の高いテスト。 npm test（または同等のもの）が5分かかるか、断続的に失敗する場合、反復ループは這うように遅くなり、フィードバック信号が劣化します。1分未満のテストは、どの開発者にとっても乗数です。タイトなサイクルで作業するAIアシスタントにとって、それらは不可欠です。

文書化されたビルドおよびテストコマンド。 Makefile、package.jsonのトップレベルスクリプトセクション、またはREADMEブロック。Bobが「これをどのように実行するか」を見つけることができる場所。それがなければ、Bobは推測する必要があり、推測は間違いが入る場所です。

実行可能なスタイル。 保存時またはCIで実行されるリンターとフォーマッター。Bobはこれらから規約を取得します。明示的で機械的にチェック可能なルールは、暗黙的な規約を毎回上回ります。

リポジトリルートのagents.md。 プロジェクト構造、キーファイル、コーディング標準、すべきこととすべきでないこと。これは、AI支援のために追加できる最も高いレバレッジファイルです。それについて考える正しい方法は、新入社員ではなくLLM用に書かれたCONTRIBUTING.mdとしてです。

コードと一緒のマークダウンのアーキテクチャドキュメント。 短いドキュメントでも役立ちます。モジュールとその境界を説明するdocs/architecture.mdにより、Bobはインポートから設計を再導出することなく「これはどこに行くのか？」に答えることができます。

途中で学んだいくつかのこと：

大きなルールファイルは信号を減らします。 数百行を超えると、モデルのパフォーマンスが低下します。すべてを1つのファイルに集中させるのではなく、領域ごとにルールを分割します。リポジトリルートのagents.md、パッケージごとのスコープ付きreadme.md。
エンジニアリングを複合する。 タスクを終了したら、Bobに関連する学習をルールファイルまたはスキルに蒸留するように依頼します。使用するにつれて、リポジトリはより生産的な環境になります。
反復し、ワンショットしない。 一貫して正しい変更を着地させるマルチターン会話は、80パーセントを着地させる単一の長いプロンプトを上回ります。

3. セキュリティとコントロール

Bobには、単一のガードレールがすべての作業を行うのではなく、連携して機能する複数の保護層があります。最初の投稿に適した短いバージョン：

すべてのアクションを手動で承認するか、ワークフローを信頼したらツールクラス（読み取り専用対書き込み）ごとに自動承認します。
.bobignoreは、Bobが読むべきでないファイル（資格情報、生成されたアーティファクト、機密性の高いもの）からBobを遠ざけます。
カスタムルールは、開発者に適用するのと同じ方法でBobにコーディング標準を適用します。
自動チェックポイントにより、望ましくない変更からの回復がワンクリックアクションになります。
プロンプトはトレーニングデータとして使用されません！

特に自動承認については、慎重に検討する価値があります。これは、チェックポイント間でBobができることの量に対する主要なコントロールの1つであり、それを広げることは生産性の向上ですが、そのエンベロープ内に何が入り、何が入らないかを決定する際に、もう少しあなたに求めます。ほとんどの開発者にとって賢明なデフォルトは、読み取り専用ツールを自動承認し、少なくとも最初の数週間は書き込みアクションを手動承認のままにし、シェルコマンドを実行したり、ローカル作業ツリーを超えてシステムに到達したりするものについては特に慎重に検討することです。リストの他のコントロール（.bobignore、カスタムルール、チェックポイント）は、自動承認を置き換えるのではなく、それと組み合わせるように設計されています。

4. 始める

ウェブサイトからIBM Bobをインストールするか、選択したターミナルを介してBob Shellをインストールします。
ベストプラクティスガイドを確認し、セキュリティガイドラインを参照してください。
実際のタスクから始めます。Bobが実際の問題を解決するのを手伝っているときに最もよく学習します。

リンク