ローカルAIでネットワーク障害を調べるには、どこまでアクセスを渡す？

支店から、電話はかけられるのに着信が安定しないと連絡が来ます。ネットワークチームは、インターフェースの変更、経路制御のイベント、一連のタイムアウトを見つけます。アシスタントが観測を整理し、次に確認する読み取り専用コマンドを提案できれば役立ちます。モデル選びは、その仕事の一部です。運用担当者は、ツールがどの認証情報を使い、何が端末の外へ送られ、モデルが変更を引き起こせるかも把握する必要があります。

Transitはネットワーク調査ツールで、2026年10月21日にクライアントをApache 2.0のオープンソースプロジェクトへ移しました。移行案内には、年間アクセスの締め切りを11月5日、ホスト型AIの切り替え予定を11月17日と記載しています。これは製品の事業上の移行日程です。どのソフトウェアが入手できるかと、特定のホスト型アカウントが使えるかは別の話です。試すビルドは、プロジェクトのリリース、README、機能文書を確認するのが確実です。

調査で「ローカル」とは何を指すか

モデルの接続先を選ぶ。Telli.sh制作。

クライアントはOllamaやOpenAI互換のエンドポイントを利用できます。OpenAIやAnthropicのキーを持ち込む方法、対象となるChatGPT PlusまたはProでのサインインプレビューも案内されています。同じ端末のOllamaサーバーに接続すれば、その端末内で推論できます。社内サーバーを指定すれば、データはその接続先に送られます。クラウド事業者を選んだ場合は、資料にある機密情報のマスキングを適用したうえで、依頼がその事業者に送信されます。

一方、証拠を集めるには、クライアントがネットワーク機器に接続できる必要があります。調査では踏み台ホスト、読み取り専用の運用アカウント、複数の機器を使うことがあります。推論先がローカルでも、クライアントが接続できる機器は絞られません。そこで効くのはネットワークの到達範囲と認証情報の権限です。

リポジトリは、用途を限定したツールと、対応ベンダー向けのコマンド許可リストを説明しています。コマンドには承認方針があり、対応機器では運用担当者が設定した規則に一致する場合に自動承認も可能です。機密情報のマスキングとコマンドのフィルタリングは、チームが個別に試せる保護層です。機器のバナーやログは、命令のような文が入っていても信頼できないテキストとして扱います。アシスタントは、そこに書かれた内容を命令として扱わずに要約できます。

運用担当者が調査する種類のスイッチとパッチパネル。参考写真 Dsimic。切り抜きとサイズ変更あり、CC BY-SA 4.0。画像の出典 · ライセンス。

原因がわかっている障害で試す

ネットワーク調査。Telli.sh制作。

ルーティングやインターフェースに既知の問題がある小さなラボを用意します。対象機器には最小権限のアカウントを使い、無関係で接続できないはずのホストも置きます。仮説と、その仮説が誤りだと判断できる観測をいくつか求めます。提案されたshowコマンドを一つ確認して実行し、同じ観測を手動で得たときの出力と比べます。

二回目は、原因が一つに絞れない症状を渡します。サービスが遅い原因は複数のネットワーク経路にあり得ます。実際の環境では、機器コマンドの出力に顧客の識別子が含まれることもあります。目印となるダミー文字列を使い、出力がどこへ送られ、記録され、保持されるかを確認します。各モードで何が見えるかを把握するまで、ラボの接続は本番の踏み台から分けておきます。

結果をエクスポートするときは、コマンド、時刻、機器の識別情報、関連する出力を、それが裏付ける仮説に添えます。運用担当者は、どの文がルーターの出力で、どの文がモデルの説明かを思い出さなくても、証拠の流れを確認できます。

リリースの整合性とローカルモデルの限界を確認する

Transitは、リリースビルドに署名がないと明記しています。リリースごとのSHA256SUMSファイルを使えば、ダウンロードしたファイルが公表されたダイジェストと一致するか確かめられます。その比較だけでは発行元の真正性は確認できません。署名済み成果物が必要なチームは、レビューしたタグから自社の配布手順でビルドする方法を検討できます。Windows用インストーラーの文書にはPowerShell 7の要件もあります。

ローカル推論はクラウド事業者への依存を減らせ、データ共有の制約がある環境にも合う場合があります。小さなローカルモデルは文脈を落としたり、複数ベンダーの出力を読み違えたり、手持ちの機器で時間がかかったりします。両方が許可されているなら、同じ既知の事例をローカルと承認済みのホスト型構成で試します。正しい仮説の数、不要なコマンド、機器の取り違え、担当者の総作業時間を測ります。

最初は、自動承認を切り、運用担当者がコマンド案を一つずつ確認する、範囲限定の証拠収集ツールとして試すのが現実的です。ラボで一貫した証拠と説明可能な報告が得られたら、どの種類の読み取り専用調査に本番で使えるかを考えます。モデルにネットワーク全体へのアクセスを与えるかという問いより、具体的で判断しやすくなります。

対象ビルドを一つ選び、制約を書き出す

v6.5.11では、チェックサムの一覧とGitHubが正規化したファイル名の不一致が修正されています。リリースとプラットフォームを選び、インストーラーを動かす前に公表チェックサムを照合します。リリースノートを読み、公式リポジトリからファイルを取得します。管理されたカタログで承認済みソフトウェアを配る組織では、その手順に従います。ダイジェストの一致は、インストールの承認とは別です。

READMEには六つの調査ツールが載っています。数が少ないことに意味があるのは、それぞれがどこへ接続できるかを担当者が把握しているときです。認証情報を付与する前に、モデルの接続先、踏み台ホスト、試験用スイッチ一台を列挙します。接続ごとに使ったアカウントを記録します。開発者が別のOllamaサーバーを指定したら、クライアントが実際に到達するアドレスを確認します。社内ネットワーク上でも、ノートPCから見れば端末外の接続先です。

1. 既知の症状と、対象機器だけに権限を絞ったアカウントを使い、ラボの事例を作ります。
2. 選んだビルドを検証し、接続先、認証情報、保持設定を確認します。
3. 次に観測すべきことと、その観測で否定できる仮説をアシスタントに尋ねます。
4. 自動承認を切った状態で一つの提案を拒否し、機器のログを確認してから、別の安全なコマンドを許可します。
5. サンプルログに無害な目印を入れます。クライアントが隠すか、端末の記録や指定接続先のどこに現れるかを調べます。
6. 結果をエクスポートし、別の運用担当者に記録を使って診断を再現してもらいます。

事業者を切り替える利用者は、設定変更後にもこの試験を行います。同じボタンでも、接続先が変われば別のデータ経路を通ります。許可されたラボで通信を観測すれば、行き先を検証できます。設定画面の画像だけでは、実際にどこへ送られたかはわかりません。

対応スイッチと汎用シェルを分けて扱う

タグで固定されたTransitの脅威モデルは、対応ベンダー向けのコマンド方針を説明しています。あらかじめ有効にした規則に一致するときは、自動承認を選べます。試行ではその設定を切り、運用担当者がすべての提案を見られます。ツールには依然として、権限を狭くした機器アカウントが必要です。承認ダイアログだけでは、サービスアカウントに最小権限を適用できません。

同じ脅威モデルは、汎用LinuxとUnixの扱いを分けています。その経路では警告を出し、コマンドごとに承認を求め、常に許可する規則は用意していません。汎用システムに対する基盤側のコマンド方針には制限がありません。組織が別の手段で範囲を強制できない限り、初回の読み取り専用試行から外します。機器の種類とアカウントも安全設計に含まれます。

別のラボ事例で、ツールが見慣れない出力に出会ったときを試せます。モデルが知らないカウンターをコマンドが返したり、同じ役割のインターフェース名がベンダーごとに違ったりします。よい応答は元の観測を引用し、解釈の違いを見分けられる次の確認を提案します。弱い応答はもっともらしい解釈を確定した事実として扱います。本番機器を見せずに、両方を採点できます。

次のシフトが使える形で結果を書き出す

診断を行った本人には、一行の結論でも便利です。シフトの引き継ぎには、最後に確認した観測、除外した可能性、残る不確実性、新しい担当者がすべてのセッションを開き直さずに確認できる項目が要ります。重要な記述のそばに証拠への参照を置きます。新しいログを見てモデルが診断を変えたら、その理由も残します。

チームがすでに使っている手作業を比較に含めます。最初の有用な観測までの時間、無関係なコマンド案の数、引き継ぎ資料を書く時間を記録します。許容できる時間で作業を終えられるなら、ローカルモデルにはプライバシー上の利点があります。難しい事例では、データ方針が許せば承認済みのホスト型モデルが実用的な場合もあります。いずれでも、接続経路と得られた証拠を明確にします。

データの行き先を一つずつ追う

構成記録には、利用者画面から送る内容、推論へ転送する内容、機器から集める内容を記します。事業者を変更したときに、何が変わったかを調べやすくなります。保持設定は接続先ごとに確認します。ローカル履歴を消しても、接続先が以前の依頼を捨てたとは限りません。

表は一般的な配置を示しています。選んだ構成で、実際の接続先とサービス設定を観測します。管理者の設定画面に、ホスト型サービスとプライベートゲートウェイで同じブランド名が出る場合があります。実際のホスト名と運用者を特定すると、データの流れを監査できます。

マスキングは架空の証拠で確認する

架空のIPアドレス、存在しない機器名、顧客IDに似せた目印を入れたラボログを作ります。方針上どれを残し、伏せ、消すかを記します。同じ試料を、チャットの要約とエクスポートなど二つの操作で使います。出力の組み立て方が違う可能性があるため、実データを扱う前に経路ごとに確認します。

長い説明文や整形済みの出力に埋め込んだ目印でも試します。認識できるフィールドはマスキングできても、文章に含まれる同じ値を見落とす場合があります。許可されていない接続先に目印が出るなら、本番機器に接続する前にその経路を閉じます。元のデータを絞って再試験すれば、どの保護が実際に効くかを確かめられます。

更新後にも評価を繰り返す

クライアントの更新後に、選択した事業者を記録し、同じラボ事例を繰り返します。コマンド許可リストや自動承認のマッチ条件が変わると、提案される操作も変わります。既定の接続先が変われば、証拠の行き先も変わります。拒否されるコマンド、マスキングの事例、既知の正しい診断をまとめて確認します。この小さな回帰テストがあれば、チームの環境が変わってもオープンソースのツールを運用しやすくなります。

ツールの制約と機器アカウントの権限を別々に調べる

読み取りツールは、すでに入手した機器のメタデータや証拠を返せます。コマンド実行ツールは、接続済みアカウントで機器に新しい証拠を求められます。コマンドを実行できない状態でも、既存情報の要約はできるはずです。モデルの接続先を有効にしたまま機器との接続を外し、この境界を試します。返答では、以前に観測した情報と、今回取得できなかった情報を区別できる必要があります。

次に、一台のスイッチは調査できても、設定モードに入れず、別のネットワーク区間には届かないアカウントで接続します。実際の変更をアシスタントに頼まなくても、自分たちのラボで拒否される経路を試せます。アプリの操作提案ログと、機器側のログイン、コマンド監査の記録を比較します。これで、ツールの方針による判断と、実際のアカウントが持つ権限を切り分けられます。

出典

• Transit v6.5.11のリリース

• タグで固定したTransitの脅威モデル

• Transitのオープンソース移行

• Transitコミュニティーリポジトリとリリース手順

• Transitのリリース一覧

• Transitの機能ドキュメント

---

仕事の背景となる会話や判断を検索できる記録にするには、Telli.shのアカウントを作成してください。