現在どのTabnineガイドラインが有効であるかを確認する方法（2026年版ガイド）

Tabnineのファイルベースのガイドラインは、他のあらゆるツールと同じように動作する部分です。これらは /.tabnine/guidelines/ ディレクトリ内のMarkdownファイルであり、このディレクトリは「1) ホームディレクトリ、または 2) プロジェクトディレクトリ内のプロジェクト単位のいずれかに配置されます」。複数のガイドラインファイルを保存することができ、Tabnine自身の表現も標準仕様というよりは比喩を用いています。「これらは、他のエージェントツールが使用する agents.md ファイルと同様のものと考えてください」。これが比喩であることに注意してください。ファイル名は AGENTS.md ではありませんし、リポジトリにそれを置いたからといって自動的にTabnineに読み込まれるわけではありません。また、サイズに関する推奨事項もあります。「guidelines.md ファイルは500行以下に抑えることが推奨されます」。

このディレクトリの外側には3つの要素が存在し、それぞれが「ファイルを読めば答えがわかる」という前提を崩してしまいます。

Admin Consoleはローカルファイルよりも優先されます。 これは肝に銘じておくべき一文です：

「ここに入力されたガイドラインは、guidelines.md ファイルに記載されているガイドラインと同じ効果を持ちますが、guidelines.md ファイルに存在する個人のガイドラインよりも優先されます。」

組織のガイドラインは「組織のすべてのユーザーおよびプロジェクトに適用」されます。つまり、最も権限のあるレイヤーは自分では読み取れない可能性があり、目の前にあるファイルよりも優先されるのです。ローカルのガイドラインがAと言い、コンソールがBと言っている場合、エージェントが従うのはコンソールのバージョンです。そして、リポジトリにはその記録は一切残りません。

反映までのタイムラグ（プロパゲーションウィンドウ）があります。 コンソールでの変更は「15分後、またはIDEや拡張機能の再起動時にIDE拡張機能に適用されます」。管理者がガイドラインを編集してから最大15分間、セッションは古いバージョンを実行し続けます。この時間枠の間、実際に有効なガイドラインセットは、ローカルファイルとも現在のコンソールの状態とも一致しません。これは、正しく設定されている2人のエンジニアが、同じコミットに対して異なるエージェントの挙動を目にする最も再現性の高い原因です。

CLIは2つの独立した配信パスを使用し、スイッチがあるのは片方だけです。 TabnineのCLIドキュメントは、「Tabnine CLIにおけるエージェントガイドラインの管理方法は、Tabnine IDEプラグインとは異なります」という警告から始まり、2つのフローを説明しています。

1つ目：「組織の指示およびサービスアカウントの指示が、エージェントの動作コンテキストに追加されます。これらの指示は、Tabnine管理者によってCLIの外部で設定されます。Tabnine CLIが起動すると、認証されたアカウントで利用可能な指示を取得し、セッションに適用します」。サービスアカウントの指示は「認証されたサービスアカウントに対して設定されている場合にのみ適用されます」。

2つ目：組み込みの Tabnine Coaching Guidelines ツールを介して利用可能なコーディングガイドライン。エージェントは「コードの記述、コードのレビュー、またはチームの標準に関する質問への回答を行う前に」これを照会できます。

そして、私たちの疑問にとって最も重要な一文がこれです：

「これらのフローは独立しています。組織およびサービスアカウントの指示は、Tabnineアカウントのコンテキストから自動的に取得されます。Coaching Guidelinesの設定は、組み込みのCoaching Guidelines MCPサーバーのみを制御します。」

つまり、/settings ダイアログから確認・切り替えができる唯一の設定である enableCoaching は、2つのパスのうちの片方しか制御していません。ドキュメントには明示的に「この設定は、組織またはサービスアカウントの指示が取得され、セッションコンテキストに追加されるかどうかを制御しません」と書かれています。これをオフにしても、ガイドラインのないセッションになるわけではありません。一方のパスが閉じられ、もう一方のパスがまだ開いているセッションになるだけです。

障害は意図的にサイレントに処理されます。 どちらのフォールバックも静かに機能低下します。「Tabnine CLIが組織またはサービスアカウントの指示を取得できない場合、セッションはそれらなしで続行されます。Coaching GuidelinesがTabnineサーバーでサポートされていない場合、組み込みのCoaching Guidelinesツールはロードされません。」

エラーは何も発生しません。ネットワークの瞬断、セッションの期限切れ、機能をサポートしていないサーバーなどがあっても、エージェントはより小さな指示セットで、何のシグナルも出さずに動作し続けます。これは、なぜエージェントは指示ファイルを無視するのかで説明したのと同じ失敗の形ですが、ここではファイル自体に問題はなく、取得（フェッチ）自体が失敗している点が異なります。

なお、Tabnineの語彙において「ガイドライン」という言葉は多くの役割を担っているため、1点明確にしておきます。上記の内容は、Tabnineのメモリ（記憶）機能の話ではありません。Tabnineは、パーソナライズ、グローバルなコードベース認識のための接続、そしてアセット、データソース、実行、アナライザー、コーチングガイドラインを備えた管理者側のContext Engineをドキュメント化しています。これらは独自の設定を持つ別個のメカニズムであり、このガイドはセッション内のエージェントの挙動を形作るガイドラインレイヤーのみを対象としています。

guidelines.md を読んで終わりにする。 これは間違った質問に答えています。ファイルはあなたが求めたものを教えてくれますが、実際に適用されているものを教えてくれるわけではありません。そして、コンソールレイヤーは明示的にそれよりも優先されます。

エージェントに指示内容を尋ねる。 何もしないよりはマシであり、Tabnineもその限定的な方法を推奨しています。「現在のセッションでCoaching Guidelinesツールが利用可能に見えるかどうかをTabnine CLIに尋ねることもできます」。しかし、ドキュメントに付記されている制限事項を読んでください。「これは実用的なチェックであり、スタンドアロンのステータスコマンドではありません」。これはツールが利用可能に見えるかどうかを教えてくれるだけで、どのガイドラインテキストがコンテキスト内にあるかは教えてくれません。また、組織の指示パスについては何もわかりません。

何かがおかしいと思ったら再起動する。 効果的ですが、検証不可能です。再起動すると、15分待つことなくコンソールの変更が即座に適用されます。また、設定の変更にはいずれにせよ再起動が必要です。「この設定を変更するには、Tabnine CLIを再起動する必要があります」。しかし、再起動で解決したとしても、情報が古かった（stale）ことはわかっても、何が古かったのかはわかりません。

管理者にコンソールの内容を読み上げてもらう。 正しいソースですが、頻度が合いません。ある一瞬、一人の人間に対しては疑問を解決してくれますが、コンソールは予告なく再び変更される可能性があります。

コンソールのガイドラインをローカルファイルに複製する。 魅力的ですが、競合を悪化させます。これで、文書化された優先順位を持つ2つのコピーが存在することになり、コンソールのバージョンが変更された瞬間、ローカルのコピーは「自信満々に間違った記録」になります。調整手段のない、矛盾し得る2つの記録が存在する状況は、メモリ競合の検出でマッピングした状況そのものです。

有効なセットを直接クエリすることはできません。できるのは、その入力を列挙し、それぞれの挙動を検出し、比較対象となる期待値を書面で保持することです。

ステップ 1：サーフェスごとに5つの入力をすべて列挙する

このプロジェクトとこのマシンにおいて、以下のそれぞれに何が存在するかを書き留めます：

プロジェクトディレクトリの .tabnine/guidelines/ — 複数ファイルがサポートされているため、guidelines.md だけでなくすべてのファイル。ホームディレクトリの .tabnine/guidelines/ — 同様。これらはすべてのプロジェクトに適用されることに注意してください。Admin Consoleの一般ガイドライン — 閲覧権限を持つ人から報告された、最終変更日付きのもの。サービスアカウントの指示 — セッションがあなた自身ではなくサービスアカウントとして認証されている場合。そして、/settings から確認できるCoaching Guidelinesツールの状態。

次に、どのサーフェス（インターフェース）について問い合わせているかをメモします。コンソールレイヤーは両方に届きます。「Admin Consoleで設定されたガイドラインは、IDEチャットセッションに適用されるのと同様に、CLIセッションにも適用されます。CLI側での追加設定は不要です」。しかし、CLIの2フローモデルとIDEの15分の反映遅延はサーフェス固有のものです。同じリポジトリであっても、ターミナルとエディタで挙動が異なるのは正常な動作です。

ステップ 2：矛盾を利用して各入力を検出する

Tabnineは利用可能なチェックを「実用的なチェックであり、スタンドアロンのステータスコマンドではない」と説明しているため、代わりに、紛れもなく無害な指示（普段は絶対に使わない命名規則や、新しい関数に対する必須のコメントヘッダーなど）を使って各ソースをテストします。

まずプロジェクトファイルをテストします。マーカーを追加し、反映の遅延を避けるために再起動してから、短い関数を生成させます。マーカーが現れれば、プロジェクトディレクトリがロードされています。

次にコンソールレイヤーをテストします。プロジェクトファイルに独自のマーカーを残したまま、管理者に異なるマーカーを追加してもらいます。どちらが表示されるかで、どちらのレイヤーが勝ったかがわかります。Tabnineのドキュメント上の答えはコンソールです。これを自分の環境で確認することには10分の価値があります。なぜなら、これが人々のメンタルモデルと最も頻繁に矛盾する事実だからです。

反映の遅延（プロパゲーションウィンドウ）を一度意図的にテストします。管理者にコンソールのマーカーを変更してもらい、再起動なしでいつ反映されるかを記録します。この遅延が実在することを知っておくことで、次の意見の相違を診断に変えることができます。

CLI's Coaching Guidelinesパスをテストするには、エージェントにガイドラインに基づくレビューを依頼します。Tabnineのドキュメントに記載されている挙動では、「ガイドラインに基づくレビューを求め、ガイドラインが利用できない場合、Tabnine CLIはルールを捏造するのではなく、設定されたガイドラインにアクセスできない旨を伝える必要があります」。正直な拒否は有用なシグナルです。もっともらしい出力を伴う沈黙こそ、注意すべきケースです。

ステップ 3：ツール外部でバージョン管理された期待値を書面で保持する

上記のテストはスナップショットを提供します。来月そのスナップショットを役立たせるのは、「答えがどうあるべきか」の記録です。

その記録には3つの特性が必要です。まず、コンソールの外部に存在する必要があります。なぜなら、コンソールはセッションから読み取ることができないレイヤーだからです。次に、.tabnine/guidelines/ の外部に存在する必要があります。なぜなら、信頼できるテキストの複製は、コンソールが変更された瞬間に誤った記録になってしまうからです。そして、すべてのサーフェスから読み取れる必要があります。CLIとIDEではセットの組み立て方が異なるためです。

そこに記録するのは、ガイドラインのテキストそのものではありません。その周囲のメタデータです。どのルールが組織レベルで適用されることが期待され、どれが個人用なのか、誰が、いつ決定し、何と置き換えたのか、です。そうすることで、「どのガイドラインが有効か」は、推測ではなく、書面による期待値と観察された挙動との比較になります。この種の記録をバージョン管理下に置く一般的なケースについては、AIのメモリをGitのように扱うで解説しています。

MemoryLakeは、その期待値を保管する場所です。現在どのレイヤーが配信しているかに関わらず、各ガイドラインの背後にある決定記録を保持します。コンソールが変更されたとき、その変更と比較するための基準が得られます。ガイドラインが消えたとき、それが何と言っていたか、なぜそこにあったのかがわかります。ここから始めましょう。

ステップ 1：APIキーを作成する

1つのリポジトリではなく、チーム用のワークスペースを作成します。組織のガイドラインは「組織のすべてのユーザーおよびプロジェクト」に適用されるため、記録は少なくともそれが記述するレイヤーと同じくらい広い範囲をカバーする必要があります。

ステップ 2：最初のメモリをアップロードする

ステップ2のテスト結果を記録します。どのレイヤーが勝ち、どのサーフェスで有効だったか。次に、現在コンソールにある各ガイドラインの背後にある決定事項（理由、日付、置き換えられたバージョン）を追加します。管理者にその履歴を一度尋ねてみてください。後から再構築するよりも、今記録する方がはるかに簡単です。

ステップ 3：AIとエージェントを接続する

使用している両方のTabnineサーフェス（IDEプラグインとCLI）を接続します。2つはガイドラインを異なる方法で組み立てるため、1つの共有決定記録を読み取らせることが、ガイドラインテキストが異なるパスで届く場合でも、ルールの理由を両方でまったく同じように利用できるようにする唯一の方法です。

2人のエンジニア間の意見の相違が診断可能になります。ある人のエージェントが規約に従い、別の人のエージェントが従わない場合、チェックリストが手に入ります。反映の遅延、サーフェスの違い、サービスアカウントの認証、またはサイレントに失敗したフェッチ。肩をすくめる代わりに、4つの仮説を立てることができます。

サイレントな機能低下が検出可能になります。文書化されたフォールバックが「セッションはそれらなしで続行される」であるため、気づく唯一の方法は、比較対象となる期待値を持つことです。マーカーテストは1分で終わり、今日気づくか、レビュー時に気づくかの違いを生みます。

管理者の変更が「見えないイベント」ではなくなります。現在、コンソールの編集は、アナウンスなしの挙動変更としてチームに届きます。日付入りの書面記録があれば、それを指摘できるようになります。

そして、推論はレイヤーの変更を生き延びます。ガイドラインは移動します（個人ファイルからコンソールへ、コンソールからサービスアカウントへ）。そして、移動するたびにテキストは書き換えられます。しかし、その背後にある決定事項は移動する必要がありません。これは、AIのメモリは機能か、それともロックインかで提起した所有権の問いの、実践的な形です。

テストするときは、待つよりも再起動してください。15分の時間枠は、通常の作業には適したデフォルトですが、診断の妨げになります。IDEまたは拡張機能を再起動すると、コンソールの変更が即座に適用されます。

個人用と組織用のガイドラインは、異なる内容について記述してください。コンソールは guidelines.md よりも優先されるため、重複はあなたが負ける競合になります。ローカルファイルは純粋に個人的な好みのために使用し、共有スタンダードはそれを強制するように設計されたレイヤーに任せましょう。

enableCoaching をグローバルなオフスイッチとして扱わないでください。これは「組み込みのCoaching Guidelines MCPサーバーのみを制御」し、組織およびサービスアカウントの指示は関係なく取得されます。テストのために本当にクリーンなセッションが必要な場合は、設定の問題ではなく、認証の問題です。

セッションがどのアイデンティティを使用しているかを確認してください。サービスアカウントの指示は「認証されたサービスアカウントに対して設定されている場合にのみ適用される」ため、CIの実行とローカルセッションでガイドラインが異なるのは正当な動作です。記録にはサーフェスと並んでアイデンティティもメモしておきましょう。

長さの推奨事項を尊重してください。Tabnineは guidelines.md を500行以下に抑えることを推奨しています。複数のガイドラインファイルがサポートされているため、1つのファイルを推奨サイズ以上に大きくするのではなく、トピックごとに分割してください。

疑わしいときだけでなく、スケジュールに基づいて監査してください。四半期に一度、マーカーテストを実行し、結果を書面による期待値と比較します。この習慣のより広いバージョンは、AIが実際に何を覚えているかを監査するにありますが、ここでは信頼できるレイヤーをセッションから検査できないため、さらに重要になります。

Tabnineのガイドラインシステムは、単一の指示ファイルよりも強力です。組織全体の強制適用、サービスアカウントのスコープ設定、タスクの途中でエージェントが照会できるツールなど、フラットなファイルでは不可能なことをすべて実現できます。その能力の代償として、有効なセットはセッション開始時に、異なる所有者、異なるサーフェス、そして文書化された遅延を持つソースから組み立てられます。

答えを出力するコマンドは存在せず、Tabnineもそう明言しています。あなたにできるのは、5つの入力を列挙し、矛盾によってそれぞれをテストし、何が有効であるべきかの書面による記録を保持することです。そうすれば、疑問は「答えられないもの」から「比較するもの」へと変わります。それこそが、「現在どのガイドラインが有効か」という問いに必要なすべてでした。

移行をまだ検討中であれば、GitHub CopilotからTabnineへの移行で、両者間で優先順位の方向がどのように逆転するかをカバーしています。これは、ここに至る上で最も驚くべき部分です。