Talk Lowy(jp)

宇宙へ向かう人工知能：軌道コンピューティング(Orbital Computing)と宇宙AIデータセンターの未来トレンド 近年、人工知能（AI）技術の爆発的な成長に伴い、大規模言語モデル（LLM）やディープラーニングインフラの膨大な電力消費と炭素排出量が世界的な課題となっています。地上のデータセンターは、電力不足や冷却システムの限界という物理的な障壁に直面しています。 このような状況の中、グローバルテック大手や宇宙スタートアップは、地球を超えた新たな解決策を模索しています。それが、宇宙空間に人工知能演算システムを構築する**「軌道コンピューティング（Orbital Computing）」 と 「宇宙AIデータセンター（Space AI Data Center）」**です。2026年のGoogleトレンドや業界の動向をもとに、AIと宇宙技術の融合がもたらす革新と、その背景にある技術的な課題について深く掘り下げていきます。 1. 軌道コンピューティングとエッジAI衛星とは？ かつて人工衛星は、宇宙で生のデータ（画像やセンサー値など）を収集し、地上局（Ground Station）へ転送するだけの単純な収集機に過ぎませんでした。しかし、転送すべきデータ量が指数関数的に増加するにつれ、地上局との帯域幅制限や転送遅延（レイテンシ）が大きなボトルネックとなっています。 軌道コンピューティング は、衛星自体に高性能なAI半導体を搭載し、宇宙で即座にデータを分析・処理する**「エッジAI（Edge AI）」**技術です。 リアルタイムデータ処理: 衛星カメラが捉えた画像から、森林火災、洪水、あるいは安全保障上の脅威などを地上に送信する前に、AIがリアルタイムで分析・検出します。 帯域幅の削減: 不要なノイズデータを破棄し、核心的な「インサイト情報」だけを圧縮して地上に送信することで、衛星通信の帯域幅を劇的に節約します。 ここで中心的な通信インフラとなっているのが、**Starlinkのレーザー通信（レーザーメッシュネットワーク）**です。衛星間のレーザー光通信により、地上局を経由することなく低軌道（LEO）上でテラバイト級のデータを超高速で転送できる宇宙のバックボーンネットワークが構築されています。 2. グローバルテック大手の宇宙AI先占競争：Go...

Slackに複数のAIアシスタントを導入して見えてきたこと OpenClaw、Manus、Antigravity、Codexの一次導入レビュー 最近、OpenClaw、Manus、Antigravity、CodexをそれぞれSlackに連携させ、実際の業務アシスタントとして活用できるかテストを行っている。 最初は単純に「どのAIが一番優秀か？」を比較するつもりだった。しかし、実際にSlackに連携して使ってみると、比較すべきポイントは予想とは全く違っていた。モデルの性能だけが重要なのではなかった。 実際には、以下の4つの要素がはるかに重要だった。 第一に、Slack内でどれだけ自然に対話できるか。 第二に、外部サービスやローカルの開発環境とどれだけスムーズに連携できるか。 第三に、トークンやクレジットのコストが許容範囲内か。 第四に、フリーズせずに安定して稼働し続けられるか。 結論から言うと、現時点では「これ一つで十分」と言い切れるツールは存在しなかった。それぞれに明確な一長一短があり、むしろ役割を分担させて組み合わせて使う方が現実的であると感じた。 Manus：対話感は素晴らしいが、コストが恐ろしい 最も人間と会話している感覚に近かったのはManusだった。 Slackで話しかけると非常に自然に反応し、短いメッセージをテンポよくやり取りするスタイルも悪くなかった。むしろ、メッセージが細切れに届きすぎて、Slackの通知が少し煩わしく感じるほどだった。 しかし、最大の問題はコストだった。 ManusはPCインストール型のツールではない。そのため、ローカルPC内のファイルを直接操作したり、ローカルで完結する作業を実行したりするには限界があった。PCと連携する方法はあるようだが、今回は一旦GitHubを連携させ、AI同士が作業内容を確認できるように構成した。 問題は、Slack内で指示を出したときだった。Manusは関連情報を探すためにSlackのメッセージ履歴をスキャンし続けるようで、その過程でクレジットが急激に消費された。実際、1回のタスク指示で1,000クレジット以上を消費した挙動の末、「Slack上で関連情報を見つけられなかった」と処理が停止することがあった。 4,000クレジットで20ドルと換算すると、成功するかどうかも分からないタス...

Slackに複数のAIアシスタントを導入して見えてきたこと OpenClaw、Manus、Antigravity、Codexの一次導入レビュー 最近、OpenClaw、Manus、Antigravity、CodexをそれぞれSlackに連携させ、実際の業務アシスタントとして活用できるかテストを行っている。 最初は単純に「どのAIが一番優秀か？」を比較するつもりだった。しかし、実際にSlackに連携して使ってみると、比較すべきポイントは予想とは全く違っていた。モデルの性能だけが重要なのではなかった。 実際には、以下の4つの要素がはるかに重要だった。 第一に、Slack内でどれだけ自然に対話できるか。 第二に、外部サービスやローカルの開発環境とどれだけスムーズに連携できるか。 第三に、トークンやクレジットのコストが許容範囲内か。 第四に、フリーズせずに安定して稼働し続けられるか。 結論から言うと、現時点では「これ一つで十分」と言い切れるツールは存在しなかった。それぞれに明確な一長一短があり、むしろ役割を分担させて組み合わせて使う方が現実的であると感じた。 Manus：対話感は素晴らしいが、コストが恐ろしい 最も人間と会話している感覚に近かったのはManusだった。 Slackで話しかけると非常に自然に反応し、短いメッセージをテンポよくやり取りするスタイルも悪くなかった。むしろ、メッセージが細切れに届きすぎて、Slackの通知が少し煩わしく感じるほどだった。 しかし、最大の問題はコストだった。 ManusはPCインストール型のツールではない。そのため、ローカルPC内のファイルを直接操作したり、ローカルで完結する作業を実行したりするには限界があった。PCと連携する方法はあるようだが、今回は一旦GitHubを連携させ、AI同士が作業内容を確認できるように構成した。 問題は、Slack内で指示を出したときだった。Manusは関連情報を探すためにSlackのメッセージ履歴をスキャンし続けるようで、その過程でクレジットが急激に消費された。実際、1回のタスク指示で1,000クレジット以上を消費した挙動の末、「Slack上で関連情報を見つけられなかった」と処理が停止することがあった。 4,000クレジットで20ドルと換算すると、成功するかどうかも分からないタス...

「PCでAIが働き、私はiPhoneで運用する」 2026年、AI開発環境は単なるコード生成を超え、**「AIオペレーティングシステム（OS）」**の時代へと進化しました。開発者が一日中IDEやSSHに縛られるのではなく、 AIエージェントが実務をこなし、人間は承認と指示を出す という構造にシフトしています。特にOpenAI Codexのモバイル対応により、いつでもどこでもiPhoneだけでシステム全体を管理できるようになりました。 💡 なぜこの組み合わせが革新的なのか？ AIにコーディングを任せるだけではありません。最大のポイントは、 社内の業務環境（Google Workspace、Slack）全体をAIと連結させる ことにあります。 Codex : メインAIエージェント（コード作成とシステム制御） MCP (Model Context Protocol) : AIが外部システムを読み書きするための標準規格 Google Workspace : GmailやDocsと連携し、障害メールの分析や議事録作成を自動化 Slack : すべてを統制する**「モバイル運用コンソール」** 🚀 完璧なAI開発環境の構築シナリオ 1. インフラ準備（メインPC） 自宅や会社のPC（Mac MiniやLinux）でCodex、MCPサーバー、Docker、GitHub連携をセットアップし、24時間稼働させます。 2. MCPによる業務ネットワーク連携 Gmail / Docs MCP : 障害通知の要約、PRDの自動更新 Slack MCP : 専用のAI運用チャンネル（例： #ai-devops ）を作成 3. モバイル（iPhone）からの遠隔操作 通勤中や外出先でも、SlackやChatGPTアプリを開いて次のように指示します。 「今朝の障害メールを要約して、Slackでの議論を元にPRを作成して。」 お昼休みにPR作成の通知が来たら、スマホでコードの差分を確認し「Approve（承認）」を押すだけです。 ⚠️ 運用の注意点（コストとセキュリティ） コスト管理 : ChatGPT Plusプランをおすすめしますが、MCPで大量のドキュメントを読み込むとトークン消費が急増する可能性があります。 徹底したセキ...

開発現場や運用組織で、システム運用の効率化のために自動化スクリプトを作成することはよくあります。最近では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！「月額サブスク型」を選んだ本当の理由 実は最初は、一度システムを構築して終わりにしようかとも悩みましたが、私は毎月費用を支払って管理を受...