AIが教えたCLIインストール方法を信じてしまった結果：ハルシネーションからハルシネーション・スクワッティングまで

AIのハルシネーション（hallucination）は事実と異なる内容をもっともらしく答える現象だ。開発ツールをインストールする際には、この問題がより直接的に影響する。説明を誤解するだけでなく、自分のコンピューターで何を実行するかを決定することになるからだ。

サムスンクラウドプラットフォームのCLI、つまりコマンドラインでサービスを扱うツールをインストールする際に、私もこのような試行錯誤を経験した。AIが案内した個人GitHubのscloudを公式のインストール方法として受け入れてしまったのだ。しかし、公式ガイドが案内していたツールはscp-cliだった。この経験から得た教訓は単純だ。リンクが実際に開くという事実だけで、公式性、最新性、自分の環境との互換性まで確認されるわけではない。

AIが推薦したツールの出所を実行前に確認する様子を表現した概念図

代表イメージ：実際の作業画面や攻撃シーンではなく、概念イラスト。

リポジトリは存在したが、私が探していた公式案内ではなかった

最初はAIが教えてくれたscloudのインストール案内に従った。個人が作成したGitHubリポジトリを公式のインストールパスだと誤認したのだ。その過程で、古いバージョンや誤った設定方法、URL構成のためにかなり苦労した。

問題はコマンドの数文字が違っていたことではなかった。どのツールの説明を基準にインストールし、設定すべきかという点からずれていたのだ。後になって公式ドキュメントを確認してみると、基本的なガイドはscp-cliを介して実行する方式だった。

ここで個人リポジトリ自体を問題だと言いたいわけではない。非公式ツールも目的に合えば有用である。ただし、非公式ツールを公式のインストールパスのように紹介すると、ユーザーはそのツールがサポートする範囲と現在のサービスの要件を区別するのが難しくなる。当該リポジトリが悪性であるという根拠はない。この記事の焦点は管理者を評価することではなく、推薦を検証する過程にある。

AIが出した答えに実際のリンクが貼ってあると安心しやすい。しかし、「そのリポジトリが存在する」と「今自分の目的に合った公式ツールである」は異なる主張だ。今回は後者まで確認する必要があった。

公式ドキュメントで確認したインストールと設定の基準

この記事を準備しながら、2026年10月21日にサムスンクラウドプラットフォームCLI Common公式ドキュメントを直接読んだ。ドキュメントにはWindowsとLinux用のダウンロードリンクがあり、Linuxでダウンロードしたファイルに実行権限を与えるコマンドとして次を案内している。

chmod +x scp-cli

このコマンドはダウンロードしたファイルの実行権限を変更する段階だ。ファイルをどこで入手したかを確認する作業を代行するものではない。ダウンロードは公式ドキュメントのOS別リンクから始めるのが基準だ。確認したページにはmacOS用のダウンロードは案内されていなかった。したがって、iMacで同じファイルがそのまま動作するだとか、別途のインストールコマンドがあるとは付け加えない。

設定もツール名から推測するものではなかった。公式ドキュメントは実行環境をJSONファイルで定義しており、Linuxでは~/.scp/cli-config.json、Windowsではユーザーホームフォルダーの下の.scp/cli-config.jsonを案内している。主要項目はauthurl、accesskey、accesssecretkey、defaultscpregionであり、一時的な資格情報を使用する際にはオプション項目session_tokenがある。実際の認証値はこの記事には含めない。

特にauth_urlは対象環境によって異なる。同じページの公式表には、for Samsungはhttps://iam.s.samsungsdscloud.com/v1/endpoints、for Sovereignはhttps://iam.g.samsungsdscloud.com/v1/endpoints、for Enterpriseはhttps://iam.e.samsungsdscloud.com/v1/endpointsと区別されている。これが、例に書かれたURL一つをすべての環境の正解としてコピーしてはいけない理由だ。デフォルトリージョンも実際の対象環境とともに確認する必要がある。

公式ドキュメントでインストールファイルと設定を確認し、APIバージョンおよびエンドポイント照会へと続く確認順序

図1. 公式ドキュメントを基に再構成した確認順序。根拠：CLI Common。以下の照会は実際の口座で実行した結果ではない。

ドキュメントが案内するサービスAPIバージョン照会の基本コマンドは次の通りだ。

scp-cli versions show

公式の例示結果にはRegion Name、Service Name、Version、Status、Endpointの列が表示される。インストールしたツールがどのリージョンのどのサービスエンドポイントとAPIバージョンを扱うかを確認する際に参考にできる。ドキュメントには--region-name、--service、--status、--timeoutの選択引数も提示されている。

ここでVersionはサービスAPIバージョンだ。CLI実行ファイル自体の配布バージョンと混同してはならない。確認したCommonページでは実行ファイルバージョンを確認する専用コマンドは見つからなかった。慣れている他のCLIを思い出し、--versionのようなコマンドを推測して記述する代わりに、配布バージョンは公式配布情報と当該ファイルのサポート案内で別途確認する必要があるという限界を残す。

コマンドごとのオプションは公式ドキュメントに提示されたヘルプで確認できる。例えば、scp-cli iam policy create --helpはポリシー作成コマンドのヘルプを見る例だ。この記事ではポリシー作成コマンド自体は実行していない。インストールファイルの実行、認証、実際のエンドポイント照会も行っていないため、インストール成功体験談や実測結果として読まないでほしい。

誤った推薦がサプライチェーンリスクにつながる時点

今回の経験は互換性と設定の問題だったが、同じ信頼方式はセキュリティ問題につながる可能性がある。ソフトウェアサプライチェーンは、私が実行するプログラムがどこで作成され、どのような経路で伝達されるかを含む。インストールコマンドをコピーした瞬間、AIが推薦した名前と配布元が自分の実行環境に入ってくる。

ツールによってはインストール過程でスクリプトが実行されることもあり、その後実行したプログラムがファイルやネットワークにアクセスすることもある。出所を確認しない状態で広い権限や認証情報を与えると、誤った推薦の影響も大きくなる可能性がある。すべての非公式ツールが危険だという意味ではない。自分の環境にコードを取り込む前に配布主体を確認する必要があるという意味だ。

この危険をより意図的に利用する方式がハルシネーション・スクワッティング（hallucination squatting）、パッケージの文脈でよく言われるスロップスクワッティング（slopsquatting）だ。AIが作り出した、元々存在しないパッケージや依存関係の名前を攻撃者が登録し、その名前で悪性コードを配布する手法である。ユーザーがAIの推薦を信じてインストールすると、最初は実体がなかった名前が攻撃者が作成したコードに接続される可能性がある。

今回のscloud経験はそれ自体がハルシネーション・スクワッティング攻撃事例ではない。既に存在する非公式リポジトリを誤って推薦された事例であり、攻撃者がAIの架空パッケージ名を先占したという事実や悪性コード、被害を確認したものではない。二つの事例を結びつけるのは、「AIの推薦を出所検証なしに実行対象とする」という信頼方式だ。

今回の経験は既存の非公式ツールの誤った推薦であり、ハルシネーション・スクワッティングは架空のパッケージ名を攻撃者が登録する別の流れであることを比較した図

図2. ユーザー経験と研究で説明する攻撃メカニズムを区別した元の図式。攻撃部分はLasso研究とTrendAI研究を基に再構成した。

研究が示すのは可能性と反復性である

Lasso Securityの2024年の研究は、AIが存在しないパッケージを推薦し、その名前が実際のインストール試行につながる可能性がある問題を扱った。核心は単純な誤答の存在よりも、誤答に登場する名前が攻撃者が占有できる配布名であるという点だ。

USENIX Security 2025の元の研究は、16のモデルが生成した576,000個のコードサンプルを分析した。研究者たちは、パッケージの幻覚が複数のモデルと設定で現れる現象であることを報告した。これは、特定のユーザーが質問を誤ったために生じたことだけでは見られないという根拠だ。ただし、当時の研究条件の結果を今日のすべてのAIツールのエラー率や実際の攻撃成功率に置き換えて言うべきではない。

名称とメカニズムも分けて見る必要がある。TrendAIの独自研究は、slopsquattingという名前の下で架空のパッケージ名と悪性登録の関連性を説明する。名称議論に参加したAndrew Nesbittの記事は、2025年4月のSeth Larsonとの会話でその名前が出た経緯を記録している。名前が付けられる前からパッケージの幻覚を悪用する問題は研究されていた。

攻撃者が名前を登録した後には、「パッケージが存在するか」だけを検査しても通過できる。そのため、存在確認だけでは不十分だ。そのパッケージが元のプロジェクトの公式配布物であるかを確認する必要がある。

次のインストール前に確認するチェックリスト

AIを使わないことよりも、実行直前に確認する基準を定める方が実務的だ。今回の経験で必要な基準をまとめると次の通りだ。

公式ドキュメントから始める。 AIが提供したリポジトリリンクをすぐに信じるのではなく、サービス公式ドキュメントがリンクしている配布元であるかを確認する。検索順位やスターの数は公式配布の証明ではない。
製品名・パッケージ名・コマンド名を区別する。 この事例のscloudとscp-cliのように、似た目的のツールを同じものとして扱わない。インストールする名前と実際の実行コマンドが異なる場合もある。
現在のサポート範囲を確認する。 オペレーティングシステム、配布時点とサポート状況、サービスAPIバージョン、リージョン、認証環境を分けて確認する。古いREADMEだけで現在のサービスとの互換性を断定しない。
インストール前に実行内容を検討する。 リモートスクリプトを直接実行するコマンドや管理者権限が必要な段階は、その理由と内容を確認する。公式の署名・ハッシュが提供されている場合は検証するが、ハッシュも信頼できる経路で入手する。
秘密と権限は遅れて与える。 初めて確認するツールに運用用の認証値をすぐに入力しない。必要な検討を終えた後、最小限の権限で使用し、設定ファイルやキーをAIの質問・公開ログに添付しない。
チームでは検証済みの配布物を再利用する。 承認された出所とバージョンを記録し、可能なエコシステムではロックファイルとハッシュを管理する。これらは検討済みの配布物を一貫して使用する手段であり、悪性かどうかを自動判定する保証書ではない。

AIにはこのように要求できる。「公式ドキュメントのリンクと実際の引用根拠をまず示し、パッケージ名と実行コマンド名、サポートするオペレーティングシステム、設定パスを区別して教えてください。確認できていないコマンドは推測しないでください。」答えを受け取った後には、そのリンクと本文を直接照合する必要がある。同じAIにもう一度尋ねるだけでは独立した検証は完了しない。

AIは使い続けるが、実行の根拠は確認する

AIはドキュメントの構造を素早く把握したり、設定項目の意味を理解するのに役立つ。今回の経験のためにその助けまで否定したいわけではない。ただし、もっともらしい説明を公式サポートの証拠として受け入れると、誤った出発点に長く固執してしまう可能性がある。

私が経験したのは、非公式のscloud案内を公式パスとして受け入れたことによる試行錯誤だった。ここからさらに一歩進むと、AIが作成した架空の名前を攻撃者が実際の配布物で埋めるハルシネーション・スクワッティングという危険も見えてくる。インストールコマンドの一行を実行する前に、「名前があるか」に加えて「誰が配布しており、自分の環境に合っているか」を確認する理由だ。

参考資料

Samsung Cloud Platform CLI Common – インストール、JSON設定、環境別認証URL、APIバージョンとエンドポイント照会。確認日 2026-10-21。
Lasso Security: Diving Deeper into AI Package Hallucinations – 2024-03-28、元の研究機関資料。
Spracklen 他: We Have a Package for You! – USENIX Security 2025 元研究。
TrendAI: Slopsquatting – 2025-06-05、独自研究と防御説明。
Andrew Nesbitt: Slopsquatting meets Dependency Confusion – 2025-12-10、名称議論当事者の記録。