はじめに
近年、LLM（大規模言語モデル）と自律型ツールを組み合わせたシステムが注目を集めています。今回、私は OpenManus のソースコードを調査し、実際にクローンしてWSL2環境で実装するまでのプロセスを追いました。本記事では、OpenManus の基本的な動作確認や実装手順を紹介するとともに、検証時に発生した出力の不安定性（タイムアウト、抽出失敗、通信エラーなど）の課題についても記述します。
1. OpenManus の調査
1.1 調査の背景と目的
-
背景:
従来のLLM単体では実現が難しかった、リアルタイムのWeb検索やブラウザ操作とLLMの連携を可能にする OpenManus に注目しました。 -
目的:
OpenManus のソースコードを調査し、どのような仕組みでWeb上の情報を取得・解析しているのかを把握した上で、実際に自分の環境で実装・検証すること。
1.2 情報収集方法
- GitHub のリポジトリを参照
- 関連するQiita記事、ブログ、公式ドキュメントをチェック
2. OpenManus のクローンと環境構築
2.1 リポジトリのクローン
ホームディレクトリ直下にクローンする場合、以下のコマンドを実行します。
cd ~
git clone https://github.com/mannaandpoem/OpenManus.git
cd OpenManus
2.2 依存パッケージのインストール
次に、依存パッケージをインストールし、Playwright のブラウザもセットアップします。
pip install -r requirements.txt
pip install playwright==1.49.0
playwright install
2.3 設定ファイルの編集
Qiitaの記事に掲載されている例を参考に、config/config.toml を作成します。例：
[llm]
model = "gemini-2.0-flash"
base_url = "https://generativelanguage.googleapis.com/v1beta"
api_key = "YOUR_API_KEY_HERE"
max_tokens = 4096
temperature = 0.0
[llm.vision]
model = "gemini-2.0-flash"
base_url = "https://generativelanguage.googleapis.com/v1beta"
api_key = "YOUR_API_KEY_HERE"
※ 実際の API キーに置き換えてください。
3. 実装の流れ
3.1 ブラウザ起動スクリプトの作成
launch_browser.py を作成し、Playwright を用いてブラウザを起動、リモートデバッグを有効にします。例：
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
print("Launching Playwright browser...")
browser = p.chromium.launch(
headless=False,
args=[
"--remote-debugging-port=9222",
"--remote-debugging-address=0.0.0.0",
"--disable-gpu",
"--disable-software-rasterizer",
"--disable-setuid-sandbox",
"--disable-dev-shm-usage",
"--no-sandbox",
"--no-zygote",
],
)
context = browser.new_context()
page = context.new_page()
page.goto("about:blank")
print("Browser is running with remote debugging at: http://localhost:9222")
input("Press Enter to exit...")
context.close()
browser.close()
3.2 OpenManus の実行
ブラウザ起動スクリプトが実行中の状態で、別ターミナルから python main.py を実行し、タスクに応じた動作を確認します。
4. 検証と出力の不安定性
4.1 実際の検証結果
今回、リクエスト「世界の天気を調査してください。また世界の天気から考えられる対流の全体像を日本語でまとめて教えて下さい。」に対して、Manus は以下のような手順で動作しました。
-
Web検索:
「world weather information」などのクエリで公式サイトや複数の天気情報サイトへアクセスし、概要情報を取得。 -
情報抽出:
世界気象情報サイトから、公式の観測データや予報に関する概要テキストを抽出。しかし、抽出対象ページによっては期待する内容が得られず、結果が「No content was extracted」となるケースもありました。 -
地域別の天気データ:
東京、ロンドン、ニューヨーク、リオ・デ・ジャネイロなど、各都市ごとの天気情報（温度、湿度、風速、天気予報）を個別に抽出し、対流パターンに関する考察に活用。 -
対流パターンの考察:
収集したデータをもとに、赤道地域と中緯度地域の違い、そして大規模な大気循環（Hadleyセルなど）に基づく対流パターンを簡潔にまとめました。
4.2 不安定な点と課題
実装中に見られた不安定な点としては、以下が挙げられます。
-
タイムアウト:
一部のWeb検索やページ遷移で、Page.goto がタイムアウトし、目的のページにアクセスできなかったケースがありました。 -
コンテンツ抽出の失敗:
あるページでは情報が動的にロードされるため、抽出ツールが期待するデータを取得できず「No content was extracted」となる状況が発生しました。 -
スクロール操作:
ページ内の情報が画面外にある場合、スクロール操作を試みたものの、適切な情報抽出に至らないケースもありました。 -
サイトごとのレスポンスのばらつき:
各サイトの構造や動作が異なるため、統一的な抽出処理が難しく、結果にばらつきが見られました。 -
通信エラー:
最終的に、プロセス終了後に Node.js 側で EPIPE エラーが発生しましたが、これは内部の通信処理で接続が切断されたために起こったものです。
4.3 今後の改善点
- タイムアウト値の調整とリトライ戦略の強化。
- ページ構造に応じた抽出ロジックの最適化。
- サイトごとの個別ハンドリングの実装。
- 内部通信やプロセス終了時のクリーンアップ処理の改善。
5. まとめ
今回の実装では、OpenManus をクローンして実際に動作させ、世界の天気情報およびそれに基づく対流の全体像を日本語でまとめるというタスクに挑戦しました。
実装プロセスでは、調査、クローン、依存パッケージのインストール、設定ファイルの編集、そして各種ツールを駆使した情報収集と抽出を行いました。
しかし、実行中にはタイムアウトやコンテンツ抽出の失敗などの不安定な出力が散見され、今後はより安定した処理とサイトごとの最適化が課題であることが分かりました。
このように、OpenManus の実装プロセスは非常にダイナミックでありながらも、実運用に向けた改善点が明確に浮かび上がる結果となりました。今後もこれらの課題に対して改善を重ね、より堅牢な自律型情報収集システムを目指していきたいと考えています。
6. 作業時間
以下は、チャット履歴などから推定した作業時間の内訳です。
-
調査と準備: 約30分
GitHubリポジトリや関連記事を調査し、どのような仕組みで動作するのか、必要な依存関係や環境設定を把握しました。 -
クローン・環境構築: 約30分
リポジトリをホームディレクトリ直下にクローンし、依存パッケージのインストール、Playwrightのセットアップ、設定ファイルの編集などを行いました。 -
実装: 約1時間
ブラウザ起動スクリプトの作成や、main.pyの実行を通じた基本動作の確認など、実際のコード実装部分です。 -
動作確認・検証: 約2時間
各種タスク（世界の天気調査や対流パターンの考察など）に対して、Web検索、コンテンツ抽出、スクロール操作、エラーハンドリングの検証を実施し、出力の不安定性などの課題を確認しました。
総計: 約4時間ほどの作業となりました。
この内訳はあくまでざっくりとした推定ですが、実装自体は1時間、動作確認や検証が2時間程度、その他の準備に約1時間ほどかかったと考えられます。