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

Slackに複数のAIアシスタントを導入して見えてきたこと (OpenClaw、Manus、Antigravity、Codexの一次導入レビュー)

Slack Multi Agents Collaborating

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ドルと換算すると、成功するかどうかも分からないタスク1回に約5ドル近くが消費されることになる。

これでは、業務アシスタントとして常時稼働させるのは負担が大きすぎる。 対話感は素晴らしいが、コストの予測が立たないツールを業務自動化に組み込むのは困難だ。

そのため、現在の基準ではManusは一旦除外することにした。

Codex:Google連携が快適で、メインアシスタント候補

Codexは、個人用業務アシスタントの観点から非常に優れたパフォーマンスを見せてくれた。

特にGoogle MCP連携がスムーズだった。カレンダーやGmailと接続することで、スケジュールの確認やメールのチェックが自然な対話フローで行える。Slackから「今日の予定を教えて」「メールを確認して」といった指示を出すだけで、実用的な秘書に近い形で機能した。

開発者向けツールとして捉えられがちなCodexだが、Google Workspaceと連携することで、むしろ強力な個人用アシスタントとしての価値を発揮した。

ただし、いくつか課題もあった。

ローカルPCと接続してCodex App形式で使用しようとすると、macOS限定の制約に直面した。筆者はWindows環境をメインに使用しているため、この点は非常に不便だった。Windows環境でもシームレスに動作すれば活用度は大幅に高まるはずだが、現状ではこれが制限となっている。

それでも、Google連携の快適さという点だけで、Codexはメインアシスタント候補として残す価値が十分にある。

現時点において、「Slackベースの業務アシスタント」としての役割はCodexが最も現実的だ。

OpenClaw:賢さは今一つだが、意外に使い勝手は悪くない

正直なところ、OpenClawはそこまでスマートだという印象は薄い。

応答の品質だけで言えば、ManusやAntigravityに劣る部分がある。時には権限エラーが発生したり、必要なモジュールをロードするのに大量のメモリを消費したりと、運用の面でもいくつか不便な点があった。

しかし、完全に切り捨てるには惜しい特徴がある。

OpenClawは、過去の会話履歴を検索して整理する能力に長けている。これは実務において想像以上に重要だ。SlackにAIを常駐させて使う場合、単発の質問に答えることよりも「過去の文脈を記憶し、必要なときに引き出す能力」の方が重要になるからだ。

もちろん、使用しているモデルがgpt-5.3-codexであっても、CodexのSlack連携より効率が良いとは言い難い。そのため、OpenClawは一旦停止させることも検討している。

外観や動作のスマートさはCodexに劣るが、対話履歴をきれいに整理し、ローカル環境と強固に連携できれば「個人作業スペースの管理人」的な役割は十分に果たせるだろう。

Antigravity:コード修正や複雑なワークフローに最適

Antigravityは、OpenClawよりも一段とスマートな印象を受ける。

特にコードの修正や複雑なタスクを依頼する際には、かなり頼りになる。単純な一問一答よりも、複数ステップからなるタスクやスケジュールされた自動ワークフローを任せる方が向いている。

そのため、Antigravityは「常時対話型の対話相手」というよりは、「実務の実行担当者」として位置づけるのが適切だろう。

ただ、安定性にはまだ課題が残る。

使用中、ポーリング処理が詰まるのか応答が途絶えることがあった。現在は応答がない場合、単に再起動して処理をやり直すことで対応している。設定の問題かもしれないが、長期間の稼働においては少し不安が残る。

それでも、複雑なコードの変更や自動化ワークフローの実行においては、十分に使い続ける価値がある。

AI同士を対話させるのは予想以上に難しい

面白い実験も行ってみた。

1つのSlackチャンネルに複数のAIを追加し、互いに対話させてみたのだ。AI同士が意見を交わし合い、一方が作業を行い、もう一方がそれをレビューするような自律的な協調体制を期待していた。

しかし、結果は静まり返っていた。

各ツールごとにメンションルール、チャンネルメッセージの検知方法、イベントトリガー、権限の設定方式が異なるためだ。ただ同じ空間に配置するだけで自動的に連携が始まるわけではない。

結局、マルチAIの協動体制を作るには、以下のような明確な構造設計が必要となる。

ユーザーの指示を受ける「メインアシスタント」 コードを修正する「実行担当者」 結果をチェックする「レビュー担当者」 SlackやGitHubの変更点をまとめる「記録担当者」

つまり、AIを単に増やすことよりも、適切な役割分担とルーティングの設計こそが重要である。

現時点での役割分担

これまでの検証結果から、以下のように役割を整理した。

Manusは対話感は良いが、コストが高すぎるため一旦除外。

CodexはGoogle連携が強力で、カレンダーやメールを扱う「メインアシスタント」に最適。

Antigravityはコード修正や複雑なタスク、スケジュール実行を担当する「タスク実行者」。ただし、応答停止の問題は継続して調査が必要。

OpenClawは賢さは劣るものの、履歴の整理に長けている。ただ、Codexに比べると現状の効率が曖昧なため、一時停止を検討中。

結論:単一のAIではなく、役割ごとのAIの組み合わせが必要

今回の検証から得られた結論は明確だ。

SlackにAIアシスタントを組み込むことは現実的である。 しかし、まだ一つのAIがすべての役割を完璧にこなせる段階ではない。

対話が得意なAI、 Google連携が得意なAI、 コードの修正が得意なAI、 会話履歴の整理が得意なAI。

重要なのは、これらをどう組み合わせて使うかだ。

これからの鍵は、「どのAIが最強か?」ではなく、「どのAIにどの役割を任せるか?」になっていくだろう。

特に興味深い点は、このようにマルチエージェント(Multi-agent)環境を直接構成して経験してみてこそ、初めて「自分にぴったりのエージェント」が何かを正確に把握して選択できるという事実だ。単一 of AI のみを使用している場合、そのツールの回答品質や小さなバグがAI自体の性能限界とだけ感じられ、何を選択すればよいか混乱してしまう。しかし、複数のエージェントを同時に起動し、互いに比較しながら仕事をさせてみると、各ツールの固有の性質や本当の強み(Google連携、履歴記憶、コード作成など)が立体的に見えてくる。最終的に自分だけの最適アシスタント体制を完成させるためには、マルチエージェント構成を経験することが必須である。

現実的なアプローチとしては、以下のような構成になる。

Codexをメインの業務アシスタントとして常駐させ、 Antigravityをコード修正や複雑なワークフローの実行担当に据える。 OpenClawは会話履歴の要約やローカル作業のサポート用途として可能性を探り、 Manusはコスト設計が安定するまで常時運用からは外しておく。

AIアシスタントの時代はすでに到来している。 しかし、今必要なのは「より賢い単一のAI」ではない。

必要なのは、実際の業務プロセスの中に複数のAIをどう配置し、コストをコントロールし、どう安定稼働させるかという「設計」である。

AIアシスタントの運用は、インフラの運用と非常に似ている。 性能だけを見るのではなく、コスト、権限、安定性、障害対応、ログ、リトライ構造まで総合的に考慮しなければならない。

AIをSlackに接続した瞬間、それは単なるチャットボットではなく、一つのオペレーティングシステムになるのだ。


Tip:アシスタントをさらに賢くカスタマイズする方法

もし使用しているアシスタントをよりスマートに進化させたいなら、多様なオープンソーススキルを集約した下記のレポジトリを直接アシスタントに学習させることを推奨する。アシスタントに対して、以下のように指示を出すだけで自動的に学習が行われる。

以下のURLから必要な機能を取り込んで統合してください。 https://github.com/LowyShin/giip-dev-agent

コメント

このブログの人気の投稿

面倒くさいORACLEの文字化け状況

ORACLEはそもそもUTF-8をサポートしてほかの言語はサポートはしているって書いてますが親切ではないようです。 現在サーバー側は昔からUS7ASCIIに設定して日本語を入れてしまい、データは7ビットASCIIモードで読み取りながら日本語のコートがOS側とクライアント側で変換しない必要があります。 クライアント側で文字化けの解決にはNLS_LANGの設定が効くクライアントが必要ですが、一部の有料クライアントにはサポートするようです。 接続構造は参考に https://www.oracle.com/technetwork/jp/content/charcterset-250314-ja.pdf の19スライドのように クライアントからNLS_LANGをUS7ASCIIに設定しても その設定した言語にもらったUTF-8のデータをクライアントが変換すると NLS_LANGを設定しても意味がないようです。 ORACLE SQL Developerがこの様です。 ODBCと直接接続は必ずUTF-8に変換してしまうのでUS7ASCIIになっているDBからはクライアントをいくら変換しても文字化けのままです。 必ずOCI接続を通じてクライアント側から読み取らないとUS7ASCIIは勝手に変換されますね。 この全ての条件が満たした無料クライアントはA5mk2の2.9.1バージョンだけですね。 A5MK2 ver.2.9.1 : https://a5m2.mmatsubara.com/download/a5m2_2.9.1_x64.zip 2.9.1 バージョンでサーバーを設定する場合Uicode変換を強制に無視するオプションがあります。 多分このバージョンの時点ではUTF-8をメインにして設計したDBが少なかったから文字化け対応のためできたオプションでしょう。 しかし、A5mk2の新しいバージョンにもまた結果の変換をしないオプションがなくなって文字化けしてしまいます。開発者はもうUTF-8ではないDBはないと思ってるでしょう。まだまだ残ってますよ~。 クライアント側からの変換などに参考になればと思います! まだ直接お仕事になさってますか? もう遅いです!ソフトウェアロボットにお仕事を任せてどの位自分の作業分量が減ってるかをご確認ください! https://talklowy-jp.b...

コピペができないときチェックすべきこと! :: よく迷うUiPathのコツ

UiPath( https://uipath.com )はMicrosoft社のWWFを改良した製品なのでVisual Studioより初心者向けに使いやすくなっている。 しかし、初心者がそのまま使うにはかなりのハドルがある。 理由は基本開発者向けの開発ツールを無理やり便利に作ってみたとしても開発の概念と考え方がないと結構躓くことが多い。 そのなかで私もよく迷ったりしていることの一つを整理しとく。 基本Activityはすぐコピぺができるので多数のUiPath Studioを開いて開発してたりする。 ここでコピペをしても反応ないときがよくある。 この場合はこれをチェックすること! 1.Sequenceがなく一つのActivityしかないところにはペーストできないのが多い。 例えば、ifの処理ボックスにはSequenceが最初はない。 そのボックスに一つのActivityはペーストできるのに2個目からはなぜか反応ない。 それで分からないまま新しいActivityを追加してたりしたが、 あそこにSequenceを入れたら解決ができるのだ! 2.正常にペーストできるはずのところに反応ない。 この場合はPackageが合わなくペーストが効かないケースが多い。 DESIGN>Manage Packagesをクリックしてコピー元のパッケージにインストールされているのにコピー先にインストールされてないパッケージを探す! パッケージを一々見るのが難しい!と思ったら メモ帳からファイルがあるフォルダにあるproject.jsonファイルを開いてみる! あそこにJSONの形式でインストールされたパッケージが見えるので比較しやすくなる! ちなみにコピペをすると変数の宣言が大変だと思うが、 そこでもコツがあるのだ! 変数の宣言はなるべく細かくしてSequence単位で管理できるようにする。 全てに影響がある変数はしょうがないから一番広く宣言するけど。 初心者向けの説明だと、 Variablesというところをクリックして変数を開いたらScopeという範囲が見える! 大体Sequenceボックスの名前を変えてないのでSequenceがすらりと表示されてるはずが、Sequenceボックスの名前を付けてたら見やすくなる。 あ...

UiPath - Excelのシート名が存在した場合の処理

UiPath.Excel Activityは活用方法によってかなり強力ですが、隠れて探せない項目が多すぎて困ったりします。 公式ドキュメントもいまいちだし…。 Excelを自動化するには協力なUiPathの機能の中でSheetの判断処理を残します。 今まではシートがあったら何とかしようとしたら見つける方法が分からなく、ErrorのExceptionで判断したりしましたが、 workbook.GetSheets.Contains("<sheet name>") があったのをいまさら見つけました; 早速試してみましたが、 messageboxにworkbookとか書いてみても出てこない…。 これはExcel Application Scopeを利用しなければなりませんでした! まずExcel Application ScopeにExcelファイルを登録! Excel Application Scope Activityの属性にOutputにwbを入力して変数に入れます。 変数に入れてからMessageBoxに wb.GetSheet.Contains("Sheet1") を入力してみると成功! 「wb.」をおした時点でいっぱい出てきましたね。 ググってみても詳しく出て着なかったのでここにまず記録 giip - Free UiPath and Rpa Integrated Orchestration Service https://giipasp.azurewebsites.net