Claude Code「Computer Use」公開。なぜAI向けファイルllms.txtが開発に不可欠になるのか

Claude CodeがGUI操作を自律実行する機能を公開した。

ブラウザを開いてクリックし、ビルドのテストまで全自動でこなす。

AIが単なるコーディングアシスタントから「自律的なソフトウェアエンジニア」に進化する瞬間だ。

開発者はブラウザ自動化ツールの選定から解放される。

同時に、AIに読ませるための「llms.txt」が新たな必須要件になる。

AIが自律的に動くからこそ、AI向けの情報構造化が明暗を分ける。

このパラダイムシフトは、僕らの開発フローを根本から覆す。

乗り遅れれば、AIの進化に取り残されるだけだ。

異常なスピードで進むAIエコシステムの激変

AI開発の現場で、信じられない規模のアップデートが重なった。

Computer Useの公開、CLAUDE.mdの公式ドキュメント公開、そしてAuto Modeのエンタープライズ展開だ。

これら3つの大型リリースが同日に発表された。

これまでAIにブラウザ操作をさせるには、外部の自動化ツールが必須だった。

これからはClaude自身が画面を見て、直接操作する。

コードを書いて、GUIでテストして、バグを直すサイクルをAIが自律的に回す。

macOS上のProプランとMaxプランユーザー向けに、リサーチプレビューとして提供が開始された。

CLIから直接GUIアプリの起動やUIのクリックが可能になる。

さらに、Auto Modeのエンタープライズ展開も注目を集めている。

コマンドを実行するだけで、承認ステップをスキップした完全自律実行が可能になった。

また、CLAUDE.mdの公式公開も開発者にとって見逃せない。

ワークフロー管理やサブエージェント戦略、検証ステップなど、AIを最大活用するためのノウハウが詰まったドキュメントだ。

その華々しいリリースの裏で、Anthropicは重大なミスを犯している。

公開パッケージリポジトリに、50万行以上のソースコードを誤って公開する事故を起こしたのだ。

未発表のモデルや機能への言及を含む、1000以上の内部ファイルが流出した。

セキュリティの脆弱性ではなく、純粋なヒューマンエラーだった。

彼らの開発スピードが異常な領域に入っている証拠だ。

エコシステムを構築するために、極めてアグレッシブなリリースサイクルを回している。

一方で、開発トレンドでもAI活用ツールが席巻している。

リアルタイム顔スワップを実現するオープンソースツールが圧倒的な支持を集めた。

AIに長期記憶を持たせるためのメモリエンジンも注目されている。

会話履歴の蓄積や検索ができ、複数のLLMに統合可能なシステムだ。

さらに、100以上のLLM APIを統一的に呼び出せるPython SDKも台頭している。

コストトラッキングやロードバランシングを備え、主要プロバイダーを管理できる。

開発者向けツールとAI活用プロダクトの勢いは止まらない。

コードベースの変更を自動的に把握するツールが人気を集めている。

スタートアップ向けの法律コンプライアンス支援ツールも話題だ。

法的リスクの早期発見と対応を自動化するプロダクトだ。

そして、Claude Codeにリアルブラウザを提供するツールも上位に入った。

テスト実行やスクリーンショット取得を直接可能にするツールだ。

しかし、同日に発表されたComputer Useによって、その存在意義が即座に脅かされている。

AI自体の進化と、AIを使いこなすためのエコシステムの成熟。

この2つが同時に、しかも猛烈なスピードで進行している。

AIが自律化するにつれて、新たな課題も浮上している。

AIに情報を正しく伝えるためのLLMO（大規模言語モデル最適化）だ。

AIが迷わずタスクを遂行するには、Web側がAI向けのコンテキストを提供する必要がある。

人間向けのUIだけでなく、機械可読なデータ構造が求められている。

情報の発信側も、AIファーストの設計に切り替える時期が来ている。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

ブラウザ自動化の終焉とLLMOの台頭

これまで開発者は、AIにブラウザを操作させるためのツール選定に悩まされてきた。

自動化CLIツールを導入しても、企業内の認証の壁にぶつかる。

SAML認証のたびにセッションが切れ、Chromeのプロセスが大量に残る。

認証を突破するために、Cookieをエクスポートしたりプロファイルを読み込んだりするハックが必要だった。

ある検証では、SAML認証が通らずに新規セッションを起動し直した結果、Chromeのプロセスが47個も残っていたという報告もある。

これは開発現場のリアルな課題だ。

別の自動化ツールを試しても、今度は既存のChromeプロファイルにタブが58個存在していたことでクラッシュした事例もある。

プロファイルコピー時に全タブのセッションを初期化しようとし、容量を超えてしまったのだ。

高速な動作を求めてPlaywrightベースのCLIを選ぶか。

それとも認証管理に強い別のCLIを選ぶか。

開発者は常にこのトレードオフに悩まされてきた。

最速のスクリーンショット取得で200ミリ秒、DOM取得で2秒かかっていたような計測も過去のものになる。

Computer Useの登場は、このパラダイムを根本から破壊する。

AI自身がネイティブなGUI操作能力を獲得したからだ。

外部のCLIコマンドを介さず、AIが直接画面を見てクリックする。

SAML認証の壁も、人間と同じように画面を操作して突破できる可能性が高い。

自動化ツールの実行時間やIPC通信のレイテンシを気にする必要がなくなる。

AIエージェントの「手」として欠かせなかった外部ツールの存在意義が揺らいでいる。

皮肉なことに、Claudeにリアルブラウザを提供する外部ツールが話題になった同日に、この機能が発表された。

エコシステムの移り変わりの残酷さを示している。

機能の重複や陳腐化が、たった1日で起きる世界だ。

そして、AIが「自律的なソフトウェアエンジニア」として動くなら、僕らのプロダクトもAI向けに最適化しなければならない。

ここでllms.txtが重要になる。

AIがサービスを理解するための、マークダウン形式のファイルだ。

プロジェクトのルートに配置するだけで、AIクローラーが情報を正確に読み取れるようになる。

SEOの次に来るものは何か。

GEO（生成AI検索エンジン最適化）やAEO（回答エンジン最適化）など、様々な用語が乱立している。

生成AIを搭載した検索エンジンでの表示を最適化するアプローチだ。

プリンストン大学の論文でも、生成AI検索エンジンの回答に表示されやすいコンテンツの特徴が実証的に分析されている。

検索エンジンがAIで回答を生成する際、どのソースを引用するかに焦点を当てている。

AEOはもともと、強調スニペットや音声検索への最適化として使われてきた用語だ。

現在ではGEOにほぼ包含されているが、マーケティング業界では依然としてAEOを軸にしたサービスが展開されている。

さらに、これらすべてを包含するAIO（AI最適化）という広い概念もある。

しかし、実務的な具体性が足りないため、開発の現場で使われる場面は少ない。

エンジニアが意識すべき土台はLLMOだ。

LLMの学習データやコンテキストに、自社のサービスをどう載せるか。

AIがあなたのサービスを「知らない」状態は、もはや致命傷になる。

検索エンジンではなく、AIの回答に引用される確率を上げる戦いが始まっている。

しんたろー：
毎日Claude Codeを叩いてる身からすると、GUI操作の自律化は本当にやばい。
これまでE2Eテストの自動化にどれだけ時間を溶かしてきたか。
ただ、Anthropicのソースコード漏洩事故を見ると、中の人たちも相当なプレッシャーで開発回してるんだろうなと推測してしまう。
50万行のお漏らしは笑えないけど、それだけ攻めてるってことだ。

AIエージェントに選ばれるためのデータ構造設計

で、僕らの開発フローはどう変わるのか。

まず、ブラウザ自動化ツールへの過度な依存を見直すタイミングが来ている。

E2EテストやGUIの確認を、AIの自律操作に委譲する準備を始める。

AIが直接画面を叩く前提で、テストシナリオを設計し直す。

複雑な認証回避のスクリプトをメンテナンスする時間は減るはずだ。

その浮いた時間で、自社プロダクトのAI対応を進める。

今すぐやるべきは、自社サービスへの「llms.txt」の配置だ。

AIが読みやすいマークダウン形式で、サービス概要や主要機能を記述する。

人間向けのランディングページとは別に、AI向けのコンテキストを用意する。

さらに、AIクローラー向けに情報を集約した専用ディレクトリを作るのも効果的だ。

プロダクト一覧や提供サービス、プロジェクト紹介などをマークダウンで配置する。

AIクローラーがそのディレクトリを参照する設計が急速に増えている。

JSON-LDを使った構造化データのマークアップも欠かせない。

AIが引用しやすい形で、価格やカテゴリなどのメタデータを提供する。

ソフトウェアアプリケーションとしての情報を、スクリプトタグ内に定義する。

AIエージェントが迷わずあなたのサービスを操作できるようにする。

これはThreadPostのようなSaaS開発においても、最優先の課題になる。

他のAIエージェントからの連携や検索性を高めることが、そのまま競争力に直結する。

人間向けのUIデザインと同じくらい、AI向けのデータ構造設計が重要になる。

SEOでやってきたことの延長線上に、AI時代の最適化がある。

用語に振り回される必要はない。

やるべきことは、AIが理解しやすく、引用しやすいコンテンツを構造化して公開することだ。

LLMの「知識」に入り込めれば、検索系AIでも非検索系AIでも自然と露出が生まれる。

GEOやAEOは、LLMOの土台の上に成り立つ依存関係に過ぎない。

LLMOをやればGEOやAEOは自然についてくる。

しかし、GEOやAEOだけをやってもLLMOは達成できない。

これが依存関係の本質だ。

エンジニアならLLMOを軸に考えるのが一番シンプルだ。

AIが自律的に動き回る世界では、機械可読なデータを提供できるサービスだけが生き残る。

人間向けの美しいデザインだけでは、AIエージェントに無視される。

しんたろー：
AI向けのディレクトリを作ってマークダウンを置くだけ。
たったこれだけの作業でAIクローラーの扱いが劇的に変わるなら、やらない手はない。
うちの構成だと、動的なドキュメント生成とどう組み合わせるかが課題になりそうだ。
AIに読ませるための専用APIを用意するのもアリかもしれない。

よくある質問（FAQ）

Q1: Claude Codeの「Computer Use」はどのような環境で使えますか？

現在はmacOS上のProプランおよびMaxプランユーザー向けに、リサーチプレビューとして提供されている。

CLIから直接GUIアプリを起動し、UIのクリックやビルドのテストなどを自律的に実行することが可能だ。

さらに、EnterpriseプランやAPIユーザー向けにもAuto Modeが展開された。

コマンド一つで承認ステップをスキップした完全自律実行がサポートされ、開発サイクルの自動化が加速している。

コードを書いてGUIで確認するまでのサイクルを、AIが全自動化できるようになる。

もはやコーディングアシスタントではなく、自律的なエンジニアとして機能する。

Q2: LLMO対策として、開発者が今すぐ始められることは何ですか？

プロジェクトのルートディレクトリに「llms.txt」を配置することだ。

AIが読みやすいマークダウン形式で、サービス概要や主要機能、ドキュメントへのリンクを記述する。

また、AIクローラー向けに構造化された情報を集約する専用ディレクトリを作成することも有効だ。

JSON-LDを用いた構造化データのマークアップも並行して行うと良い。

これにより、AIエージェントがあなたのサービスを正確に理解し、操作や引用がしやすくなる。

SEOの延長として、AI向けのコンテンツ整備をルーチンに組み込む必要がある。

Q3: Claude Codeにブラウザ操作をさせる場合、外部ツールはもう不要ですか？

「Computer Use」の登場により、AI自身が直接GUIを操作できるようになる。

将来的には外部のブラウザ自動化CLIへの依存は確実に減る見込みだ。

ただし、現時点ではプレビュー段階であり、高速なDOM取得が求められる場面もある。

複雑なSAML認証のセッション管理が必要な場合は、既存ツールの併用やスクリプトによる回避が現実的なケースも残っている。

プロジェクトの要件に合わせて、段階的に移行していくのが賢明だ。

AIの自律操作能力が成熟するまでは、適材適所でツールを使い分けることになる。

しんたろー：
外部ツールが完全に不要になるまでは、もう少し時間がかかりそうだ。
プレビュー版の挙動を見ながら、どこまでAIに任せるか見極める必要がある。
とはいえ、この進化のスピードを考えると、来年には「昔はCLIでブラウザ操作してたよね」って笑い話になってる気がする。

変化の波に乗る覚悟

AIが自律的にコードを書き、テストを回すパラダイムシフトが起きている。

僕ら開発者は、AIが迷わず動けるように情報を構造化する側に回る必要がある。

変化のスピードはエグいが、乗るしかない。

👉 ThreadPostでSNS運用を自動化する