スキップしてメイン コンテンツに移動

投稿

Antigravity IDEにメッセンジャーを接続してみた — MCP連携の実体験レビュー

Antigravity IDEにメッセンジャーを接続してみた — MCP連携の実体験レビュー Auto Acceptが消えた日 昨日、Antigravity IDEがアップデートされ、突然 Auto Accept機能が無効化 されました。 AIがコードを提案するたびに、一つひとつAcceptボタンを押さなければならない状況。最初は大したことないと思っていましたが、実際に体験してみるとその煩わしさは相当なものでした。 (最初はどうやってこれを全部押して生きてたんだろうって、今さらながら不思議;;) そこで仕方なく、新機能タブを漁り始めました。 発見:外部メッセンジャー連携機能! アップデートノートを見ていたところ、興味深い機能を一つ発見しました。 外部メッセンジャー連携サポート — MCP(Model Context Protocol)を通じて、SlackやDiscordなどの外部メッセンジャーとAIエージェントを直接接続できるようになりました。 この機能、実はOpenClaw(Claudeベースの自律エージェント)を意識したポジショニングのように見えます。メッセンジャーからAIに直接業務を指示する方式は、すでにOpenClawが核心的な競争力として打ち出していた部分ですから。 「お、面白そう!」と思って、すぐに試してみることにしました。 MCP連携の実践 — 迷走また迷走... MCPサーバーの設定は、思ったより簡単ではありませんでした。AntigravityのエージェントパネルでMCPストアを見つけ、Slack MCPサーバーを接続する過程で、認証トークンの設定やワークスペースの権限設定など、いくつかのハードルがありました。 正直、かなり迷走しました。公式ドキュメントがまだ不十分で、設定ファイルを直接編集しなければならない部分もありました。 でも ついに成功! メッセンジャーからAntigravity AIエージェントに直接メッセージを送れるようになりました。 連携後の第一印象 最初にメッセージを送った時、AIの反応はなかなか印象的でした。質問に対して、細かく詳しく、むしろ長々と答えてくれたんです。OpenClaw + ChatGPTの組み合わせより、むしろ良いかもしれないと思いました。 しかし... トークン...
最近の投稿

【AIの豆知識】Gemini 3.5 Flash vs 3.1 Pro、トークンがあっという間に溶ける理由と賢いモデル選択ガイド

【AIの豆知識】Gemini 3.5 Flash vs 3.1 Pro、トークンがあっという間に溶ける理由と賢いモデル選択ガイド こんにちは!最近、Googleの次世代AIラインナップである Gemini 3.5 Flash と Gemini 3.1 Pro を使ってみて、「あれ?なんでこんなにトークン(コスト)がすぐに消えちゃうの?」と慌てた方も多いのではないでしょうか。 少し質問しただけなのにトークン制限に引っかかったり、高額な請求が来たりする泣きたくなる状況…。一体なぜこんなことが起こるのか、そして お財布を守りながらAIの効率を最大化するモデルやオプションの選択基準 を総まとめします! 1. 私のトークンはどこへ?犯人は「Thinkingモード」 Google Gemini 3.xラインナップの最強の武器は、ズバリ「内蔵型の高度な推論(Thinking)機能」です。これは、AIが最終的な答えを出す前に、内部で深く考える段階を経るというものです。 ここに落とし穴があります。 AIが内部で頭をフル回転させながら使った独り言(推論トークン)が、すべて「出力(Output)トークン使用量」に含まれて計算される という点です! Thinking (High) モードの恐ろしさ: ユーザーが1行の質問を投げただけでも、AIは完璧な答えを出すためにバックグラウンドで独自にエージェントループを回し、何万ものトークンを消費してしまいます。見た目は短い回答でも、実際には莫大なトークンが消費されている元凶なのです。 拡大された出力ウィンドウ: Gemini 3.5 Flashは、一度に出力できる上限が 65,536トークン へと大幅に増加しました。モデルが長文を書いたり、深く考え始めたりすると、たった1回の会話でトークンが空っぽになってしまいます。 2. Geminiモデル別「Thinkingレベル」によるトークン消費量の比較 すべてのモデルの最大入力は100万トークン、最大出力は65,536トークンで同じですが、 Thinkingの設定によって内部トークンの配分が完全に変わります。 比率と体格が異なる3つの設定( 3.5 Flash - Medium 、 3.1 Pro - Low 、 従来の3 Flash - High )のトークン使用量を明...

【AIの豆知識】Gemini 3.5 Flash vs 3.1 Pro、トークンがあっという間に溶ける理由と賢いモデル選択ガイド

【AIの豆知識】Gemini 3.5 Flash vs 3.1 Pro、トークンがあっという間に溶ける理由と賢いモデル選択ガイド こんにちは!最近、Googleの次世代AIラインナップである Gemini 3.5 Flash と Gemini 3.1 Pro を使ってみて、「あれ?なんでこんなにトークン(コスト)がすぐに消えちゃうの?」と慌てた方も多いのではないでしょうか。 少し質問しただけなのにトークン制限に引っかかったり、高額な請求が来たりする泣きたくなる状況…。一体なぜこんなことが起こるのか、そして お財布を守りながらAIの効率を最大化するモデルやオプションの選択基準 を総まとめします! 1. 私のトークンはどこへ?犯人は「Thinkingモード」 Google Gemini 3.xラインナップの最強の武器は、ズバリ「内蔵型の高度な推論(Thinking)機能」です。これは、AIが最終的な答えを出す前に、内部で深く考える段階を経るというものです。 ここに落とし穴があります。 AIが内部で頭をフル回転させながら使った独り言(推論トークン)が、すべて「出力(Output)トークン使用量」に含まれて計算される という点です! Thinking (High) モードの恐ろしさ: ユーザーが1行の質問を投げただけでも、AIは完璧な答えを出すためにバックグラウンドで独自にエージェントループを回し、何万ものトークンを消費してしまいます。見た目は短い回答でも、実際には莫大なトークンが消費されている元凶なのです。 拡大された出力ウィンドウ: Gemini 3.5 Flashは、一度に出力できる上限が 65,536トークン へと大幅に増加しました。モデルが長文を書いたり、深く考え始めたりすると、たった1回の会話でトークンが空っぽになってしまいます。 2. Geminiモデル別「Thinkingレベル」によるトークン消費量の比較 すべてのモデルの最大入力は100万トークン、最大出力は65,536トークンで同じですが、 Thinkingの設定によって内部トークンの配分が完全に変わります。 モデルと設定 (Thinking Level) 脳の稼働率 (推論の深さ) 平均的な内部推論トークン消費 特徴と体感 Gemini 3.5 Fl...

「GPUを持つ者が勝つ」という錯覚:AI時代の真の権力、電力網(Grid)

「GPUを持つ者が勝つ」という幻想 現在の市場を支配している見方は、「最も多くのGPUコンピューティングパワーを確保する者がAI時代の覇権を握る」というものです。しかし、これはすぐに打ち砕かれる致命的な錯覚です。 迫り来る真のボトルネック(Bottleneck)は、演算装置ではなく、物理的な**「電力(Power)」**です。莫大な資本を投じて最新のGPUデータセンターを構築しても、それをフル稼働させるための膨大かつ安定した電力供給を受けられなければ、その高価なGPUは単なる鉄くずとして腐っていくことになります。 電力の暴食:AIが送電網に与える衝撃 最近のグローバル動向を見ると、AIインフラの電力需要は既存のクラウド施設のそれを軽く上回っています。より大きく複雑なモデル(LLM)を学習させ、推論(Inference)するプロセスは、莫大なエネルギーを要求します。2030年までに世界のデータセンターの電力消費量は現在の2倍以上に増加すると予測されており、その成長の核心的な原動力は間違いなくAIです。 さらに致命的な問題は、AIワークロードの**不規則性(Spikiness)**です。従来の産業用電力は予測可能で徐々に変動しますが、AIシステムは集中的なモデル訓練時に瞬間的に巨大な電力を吸い上げる「電力の暴食」パターンを示します。老朽化した送電網と配電インフラは、このような急激で巨大な電力負荷の変動に耐えられるように設計されていないため、いつでも地域電力網に致命的な不安定をもたらす可能性があります。 権力の移動:ハードウェアからエネルギーへ このような物理的限界により、間もなくAI市場の真の権力は「GPUの所有者」から**「エネルギー(電力網)の確保者」**へと完全に移動することになります。 世界的なテック企業は、自らが確保した莫大なGPU資産を遊ばせないために、いかに高い代償を払ってでも「安定してGPUを稼働させることができる物理的な電力網(Grid)を備えた拠点」を探し求めるようになるでしょう。そのために莫大な資本が原子力、再生可能エネルギー、そして独自の電力網(Bring Your Own Power)の構築に投入されています。 結論として、AIを訓練し駆動するための 物理的インフラおよび電力網の統制権 を持つ者が、未来のテクノロジー市場の生...

Claude Codeは本当に「OS」なのか?技術的真実と新しいパラダイムの境界線

Claude Codeは本当に「OS」なのか?技術的真実と新しいパラダイムの境界線 最近、開発者コミュニティで Claude Code を巡る興味深い議論が起きています。ある人は「革新的なAIオペレーティングシステム(OS)」と呼び、またある人は「単なるターミナルアプリだ」と一線を画します。 果たしてどちらが正しいのでしょうか?結論から言えば、 どちらの視点もそれぞれの真実を語っています。 このツールをどう定義するかによって、開発の未来の見え方が変わってきます。 1. 技術的事実:Claude CodeはOSではありません 厳格な技術的観点から言えば、OSとはCPUやメモリ、ストレージなどのハードウェアリソースを直接管理し、アプリケーションに割り当てるソフトウェアを指します。macOS、Windows、Linuxがそれにあたります。 Claude Codeは、これらのOSの「上で」実行される一つの アプリケーション です。ハードウェアを直接制御するのではなく、ターミナル(シェル)を通じてOSのコマンドを代行する「エージェント」に近い存在です。したがって、「技術的にはOSではない」という主張は100%正しいです。 2. パラダイムの変化:なぜ「OS」のように感じられるのか? では、なぜ多くの人々がこれをOSと呼びたがるのでしょうか?それは、コンピューターを扱う**「方式」**が根本的に変わろうとしているからです。 かつては、ユーザーが直接OSコマンドを入力し、ファイルを管理していました。しかし、Claude Codeを使えば、私たちはAIに「意図(Intent)」を伝えるだけで、AIが背後でファイルを探索し、Gitを操作し、コードを修正します。 つまり、ユーザーの立場から見ると、 Claude Codeは実際のOSを完全に抽象化して覆い隠す、新しいインターフェース層 となります。カーネル(Kernel)を意識しなくなったように、今やターミナルコマンドすら意識しなくなるのです。この観点では、Claude Codeは「AIベースの開発運用環境」、すなわち比喩的な意味でのOSの役割を果たしていると言えます。 3. 反感のない共存:「エージェンティック・オーケストレーター」 ここで、二つの視点を統合することができます。Claude Codeは既存のO...

Chromeはなぜ私のPCに4GBのAIモデルを密かにダウンロードしたのか? — Gemini Nano、ローカルAI、そしてブラウザの未来

Chromeはなぜ私のPCに4GBのAIモデルを密かにダウンロードしたのか? — Gemini Nano、ローカルAI、そしてブラウザの未来 最近、X(旧Twitter)やLinkedInを中心に、非常に興味深く、一方で懸念の声が混じった投稿が拡散されています。 要約すると以下の通りです: 「Chromeがユーザーの許可なく、バックグラウンドで約4GBのAIモデル(weights.bin)をダウンロードしており、これはGoogleのオンデバイスAIであるGemini Nanoモデルである」 同時に、以下のような批判も相次いでいます: ユーザーが明確に同意した覚えがない。 手動で削除しても再びダウンロードされる。 「AIモード」は実際にはクラウドベースなのに、ユーザーにローカル処理だと誤解させている。 ブラウザがますますユーザーPCのリソースを占有するプラットフォームへと変貌している。 単に「Googleがまた何かを密かに仕込んだ」という陰謀論として片付けるには、この論争の根底にはブラウザ技術の巨大なパラダイムシフトが隠されています。本記事では、技術的な視点から何が事実であり、私たちはこれをどう捉えるべきか整理してみます。 1. 実際にChromeはローカルAIモデルをダウンロードしている 結論から言うと、 この主張は事実に近いです。 現在のChrome内部には、Gemini Nanoのためのローカル推論モデルファイルが実際に存在します。 ユーザーPCの以下のパスを確認すると、その実体を確認できます: Windows: %LOCALAPPDATA%\Google\Chrome\User Data\Default\OptGuideOnDeviceModel macOS: ~/Library/Application Support/Google/Chrome/Default/OptGuideOnDeviceModel このフォルダ内には weights.bin というファイルが存在し、そのサイズは約 4GB 前後です。このファイルはGoogleが開発した軽量LLMである Gemini Nano の重み(Weights)ファイルであり、ブラウザ内で直接AI推論を実行するために使用されます。 2. Googleはなぜ...

LLMによるUI生成の革新、Hyperscribeの分析と代替ツールの比較

人工知能(AI)と大規模言語モデル(LLM)を活用してリアルタイムでUIを生成する**Generative UI(生成型UI) 技術が、Web開発の新たなパラダイムとして定着しつつあります。しかし、モデルが直接全体のHTMLとCSSを生成する方式は、コストと安定性の面で限界があります。この問題を解決するために登場したオープンソースツールである Hyperscribe **の主要機能を分析し、類似ツールと比較してみます。 1. Hyperscribeとは? Hyperscribeは、LLMがHTMLドキュメント全体を作成する代わりに、事前に定義された**セマンティックコンポーネントJSON(エンベロープ)**のみを出力するように強制し、それを独自のレンダラーで画面に描画するツールです。 主なメリット トークンコストを80〜90%削減 : HTMLの生成には大量の出力トークンが必要ですが、HyperscribeのJSONエンベロープはわずかなトークンで同じ画面を構成できます。 スキーマ検証と安定性 : JSON出力はレンダリング前に厳密なスキーマ検証を受けます。壊れたHTMLが画面に表示されるのを防ぎます。 オフラインとマルチエージェントの再利用 : Claude Codeプラグインをはじめ、Codex、Cursorなど、JSONを出力できるすべてのエージェント環境と結合できます。 2. 類似ツール(Generative UI)との比較分析 A. Vercel AI SDK ( json-render / Generative UI) Reactエコシステムと統合され、AIチャットボットをWebアプリケーションの内部に直接統合する際に使用されます。一方、Hyperscribeは開発者のCLIやエージェントツールチェーンで活用する独立したレンダラーの性格が強いです。 B. CopilotKit (AG-UI) 既存のアプリケーションにAIコパイロットを簡単に追加できるライブラリです。これもプロダクションサービス(アプリ/Web)に組み込むためのソリューションに近いです。 C. JSON Crack & JSON Hero LLMが吐き出す膨大で複雑なJSONデータを直感的なグラフやツリー構造で視覚化するビューアです。完成された...