Talk Lowy(jp)

開発現場や運用組織で、システム運用の効率化のために自動化スクリプトを作成することはよくあります。最近ではAIの助けを借りて、誰でも素早く簡単にスクリプトを生成できる時代になりました。しかし、 同じAIツールを使って同じ目的のスクリプトを作成しても、チームメンバーに愛されるスクリプトもあれば、そっぽを向かれるスクリプトもあります。 その理由は何でしょうか？ 最近、同じ現場でスクリプトを主に開発する同僚と私の事例を通じて、 ユーザーに選ばれる自動化ツールの核心 について話したいと思います。 「動くけど、手間がかかりすぎる」 同僚が作ったスクリプトは、確かに要求された「目的」を達成するコードでした。しかし、スクリプトを実行するための過程が問題でした。 スクリプトを実行するために 手動でGatewayサーバーに接続 しなければならない。 ログイン後、必要な 情報を手動で照会 しなければならない。 ユーザーが直接状態を確認し、必要な部分だけを選んで スクリプトのパラメータとして入力 して初めて実行される。 結局、このスクリプトを使うためには、作業者がシステムの構造をよく理解している必要があり、実行の前後で緊張を緩めることができませんでした。「ツール」を使うために「人」が合わせなければならない状況だったのです。 「ワンクリックで全部やってくれる」 一方、私がチームに提供したスクリプトの方向性は異なりました。 ユーザーが 目的だけを選択 すれば、 スクリプトが目標対象の Gatewayサーバーに勝手に接続 し、 必要な 情報を自ら収集 してユーザーに提示します。 ユーザーが内容を確認して「次へ（Next）」を押すと作業が安全に遂行され、 実行前後の結果を比較 し、報告しやすい形で 証拠（Evidence）ファイルまで自動的に残します。 このスクリプトを使うための**事前準備は「ゼロ」**です。結局、チームメンバーは私のスクリプトだけを使うようになり、同僚は自動化業務から手を引くことになりました。 コーディングスキルではなく「UX（ユーザー体験）」の違い 同じAIでコードを書くのに、なぜこのような結果の違いが生じるのでしょうか？ 正解はまさに**UX（ユーザー体験）**にあります。 依頼者が「こういう作業をするスクリプトが必要です」と...

社員1人分の給与で全社員に1:1のAI秘書を導入した結果 (ft. AI Assistant Ops) こんにちは！最近、周りの経営者の方々や実務担当者の方々にお会いすると、皆さん口を揃えて「AI導入」の話をされますよね。私も最初は半信半疑でした。「本当に我が社に必要なのだろうか？」「社員の仕事を奪ってしまうのではないか？」と思っていましたが、最近導入した「AI Assistant Ops」サービスのおかげで、その考えが完全に覆りました。実際に使ってみて肌で感じたリアルな感想を共有したいと思います。 1. 報告書の山から脱出！営業効率が劇的に向上 以前は毎度、社員たちに「今月の状況はどうだ？」「前月比の変動事項のレポートをまとめてくれ」と指示していました。社員たちは報告書の作成に追われ、本来最も重要であるはずの営業活動の時間を奪われ、私自身もレポートを待つ時間がもどかしくて仕方がありませんでした。 しかし、今はただAIに質問するだけです。誰がどのような状況なのか、どんな変化があるのか、リアルタイムのレポートをすぐに受け取ることができます。 雑務の劇的な削減: 社員たちは報告用の雑務が大幅に減ったため、完全にお客様に集中できるようになりました。 生産性の極大化: 人員を増やすことなく、社員1人あたりがカバーできる顧客数が増えたため、自然と売上が向上するのを実感しています。 2. エース社員が退職しても安心な理由：「社内情報の資産化」 私が最も心強く感じているのは、全社員にカスタマイズされた「1人1AI秘書」ができたことです。我が社のデータと、エース社員の営業ノウハウが毎月継続的にAIに学習（ファインチューニング）されます。 これが本当に画期的なのですが、 仕事のできるエース社員が急に退職したとしても、そのノウハウが社内のAIにそのまま残っているため 、営業活動全体のクオリティを維持できる点です。逆に、まだ仕事に慣れていない新入社員が入ってきたとしても、賢くなったAI秘書のサポートを受けることで、すぐにベテランのように仕事ができるようになり、組織全体の平準化が実現しました。 3. 一度作って終わり？NO！「月額サブスク型」を選んだ本当の理由 実は最初は、一度システムを構築して終わりにしようかとも悩みましたが、私は毎月費用を支払って管理を受...

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、トークンがあっという間に溶ける理由と賢いモデル選択ガイド こんにちは！最近、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、トークンがあっという間に溶ける理由と賢いモデル選択ガイド こんにちは！最近、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を持つ者が勝つ」という幻想 現在の市場を支配している見方は、「最も多くの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を訓練し駆動するための 物理的インフラおよび電力網の統制権 を持つ者が、未来のテクノロジー市場の生...