マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250428
内容紹介
最小限のMCP Host/Client/Serverをスクラッチで実装する、LangChain4Jで雑なAIコーディングエージェントを作る、Reasoning能力を付与したLLM ABEJA-QwQ32b-Reasoning-Japanese-v1.0の公開、ゲーセン運営者「客から『音ゲーのとある面でコンボが外れるからメンテして』と言われ客の前でその面をフルコンボして見せたバイトを大説教した」→「何が悪いの？」で意見分かれる
出演者
関連リンク
この記事は、AIエージェントの中核技術であるMCP (Model Context Protocol) の内部実装を理解することを目指し、Host、MCP Client、MCP ServerをRubyでゼロから実装した過程を解説しています。MCPの基本的な解説や活用事例は多くありますが、内部の仕組みについて、仕様書だけでは理解が難しいと感じる人に向けて、実装を通じて学びを深めることが目的です。
MCPはHost、MCP Client、MCP Serverの3つの要素で構成されます。
- Hostは、ユーザーからの入力を受け取り、LLM（大規模言語モデル）との対話を管理し、最終的な結果をユーザーに表示する役割を担います。ClineやClaude Desktopのようなアプリケーションがこれに当たります。
- MCP Clientは、Hostからの指示を受けて、MCP Serverに対してリクエストを送信し、その結果をHostに返します。
- MCP Serverは、MCP Clientからのリクエスト（特定の機能の実行要求など）を受け取り、必要な処理を実行してClientに応答を返します。Figma MCPやFirecrawlなどがServerの例です。
ClientとServer間の通信には、メッセージ形式としてJSON-RPCが使われ、通信手段としてはstdio（標準入出力）やStreamable HTTPが推奨されています。この記事では実装の簡易さからstdioが使われています。stdioによる通信とは、Serverプロセスを起動し、その標準入出力を介してメッセージをやり取りする方法です。
実装例として、ユーザーが「サイコロを振って」といったメッセージを入力すると、LLM（Host）がそのメッセージとServerが提供する機能（Tool）のリストを組み合わせて、どのTool（この場合はサイコロを振る機能）を使うべきか判断します。HostはClientを通じてServerにToolの実行を依頼し、Serverがサイコロを振った結果を返します。Hostはその結果をLLMに伝え、LLMが最終的な応答メッセージを生成してユーザーに返します。この過程では、Hostはユーザー入力に対して通常2回LLMと通信します。
ClientとServerは、初期化、操作、終了という3つのフェーズを経て通信します。
- 初期化フェーズでは、ClientとServerがお互いの準備ができたことを伝え合います。
- 操作フェーズでは、ClientがServerに対して「利用可能なToolのリストをちょうだい (
tools/list)」とか「このToolを実行して (tools/call)」といったリクエストをJSON-RPCメッセージとして送り、Serverがそれに応じた処理結果をJSON-RPC形式で返します。 - 終了フェーズでは、ClientがServerプロセスを適切に終了させます。
今回のスクラッチ実装は、MCPの仕組みを学ぶための最小限のものであり、エラー処理や認証などの実用的な機能は含まれていません。実際の開発では、これらの機能を含む公式のSDKを利用するのが一般的で効率的です。この記事で紹介された実装は、SDKの内部でどのような通信が行われているかを理解するのに役立ちます。
引用元: https://zenn.dev/razokulover/articles/9a0aee8ceb9f3f
この記事では、Java向けの簡単なAIコーディングエージェントをLangChain4Jというライブラリを使って作る方法が紹介されています。新人エンジニアの皆さんも、AIを使った開発がどういうものか、イメージをつかめる内容です。
作ったエージェントは、「ユーザーの指示を受けてJavaコードを生成し、ファイルに保存して実行する。もしエラーが出たら、エラーメッセージを見てコードを修正し、再び保存・実行を繰り返す」という、コード作成とデバッグの基本的な流れを自動で行うものです。
このエージェントを作る上で重要な役割を果たすのが、LangChain4Jの「Tool Calling」という機能です。これは、AIモデル（LLM）に、あらかじめ定義しておいた外部の機能（ツール）を呼び出させる仕組みです。この記事では、Javaのコードをファイルに保存するsaveCodeツールと、保存したファイルをコンパイル・実行するexecuteCodeツールを用意しています。AIは、自分で考えたコードを保存したり、実行結果を確認したりするためにこれらのツールを使います。
エージェントがどのように振る舞うかは、「システムプロンプト」というAIへの指示文で細かく設定します。「Javaコードを生成するエージェントであること」「生成したコードをsaveCodeで保存し、executeCodeで実行すること」「実行エラーが出たらコードを修正してやり直すこと」などをシステムプロンプトに記述することで、AIに目的の作業をさせることができます。
筆者は、実際にこのエージェントにJTableを使ったJavaコードを作らせて実行できた際に「おぉぉ～」と声が出たと書いており、AIがコードを書いて動かす面白さが伝わってきます。コンパイルエラーが発生しても、それをAIが自分で修正して再度実行する様子も確認できたそうです。
全体のコードはGitHubのGistで公開されています。どのようなJavaコードでツールやプロンプトを設定しているか、具体的な実装に興味があれば参照すると良いでしょう。
ただし、記事の追記として、LangChain4JのバージョンによってはTool Callingがうまく動作しないことがある（例: beta3はNG、beta2はOK）という情報も共有されており、ライブラリのバージョン選びには注意が必要な場合があることが分かります。
この記事を読むことで、LangChain4Jを使ってAIにコードを書かせ、実行させる、といった具体的なAIエージェント開発のイメージを掴むことができるでしょう。自分の手で簡単なAIツールを作ってみたいという方にとって、参考になる取り組みです。
引用元: https://nowokay.hatenablog.com/entry/2025/04/25/030248
ABEJAが、経済産業省とNEDOが進める日本の生成AI開発力強化プロジェクト「GENIAC」の一環として、新しい大規模言語モデル（LLM）であるABEJA-QwQ32b-Reasoning-Japanese-v1.0を公開しました。
このモデルの最大の特徴は、「Reasoning能力」を持っている点です。Reasoningモデルとは、回答を生成する前に、人間が考えるように一度思考プロセスを経ることで、複雑な問題や技術的な問い、推論が必要なタスクに対して、より正確で質の高い応答ができるようになるモデルのことです。
モデルは、Alibaba社が開発したQwen2.5-32B-Instructをベースに開発されました。Reasoning能力を獲得するために、同じくReasoning能力を持つQwQ-32Bというモデルの「思考に関わる部分」を、既存のモデルに賢く組み合わせる「モデルマージ」という手法が使われています。さらに、日本人ユーザーがより自然に使えるように、たくさんの日本語データを使った追加学習（SFTやDPOと呼ばれる、モデルの応答を調整する学習手法）も行われました。これにより、日本語での思考過程や回答が安定して出力されるよう性能が向上しています。
開発されたモデルの性能は、LLMの日本語能力を測るための標準的な評価方法の一つである「Japanese-MT-Bench」で評価されました。その結果、32Bというモデルサイズでありながら、GPT-4oやClaude 3.5 Sonnetといった有名な商用モデルの一部バージョンと比較しても遜色ない、高いスコアを達成しています。これは、ベースとなったモデルや、マージに使われた元のモデルよりも性能が大幅に向上していることを示しており、国産の強力なLLMとして非常に期待できる結果です。
このモデルはApache 2.0ライセンスで公開されているため、個人や企業が商用目的で自由に利用することができます。
利用する際にはいくつか注意点があります。特に、モデルの推奨するパラメータ設定（例えば、生成される文章のランダム性を調整するTemperatureやTopPなど）を使うことや、モデルの仕様に合わせた正しい入力形式（ChatTemplate）で使うことが推奨されています。システムプロンプト（AIに役割や前提条件を与える最初の指示）は、このモデルでは入れない方が性能が良いとのことです。
現時点での課題としては、思考過程が意図せず英語や中国語になる場合があること、思考プロセスが長すぎたり同じ内容を繰り返したりする場合があること、そして思考過程と最終的な回答が完全に分かれずに混ざってしまう場合があることが挙げられています。これらの課題は今後の改善で解決されていく見込みです。
ABEJAは今後もReasoning能力を持つLLMの開発を進めていく方針です。今回のモデル公開は、国内での高度な日本語LLM開発が進んでいることを示しており、エンジニアが新しいAI技術を活用する上で参考になる情報と言えるでしょう。
引用元: https://tech-blog.abeja.asia/entry/geniac2-qwen25-32b-reasoning-v1.0
この記事は、あるゲームセンターで実際にあったお客様対応の出来事とその対応について、インターネット上で様々な意見が出ていることについてまとめたものです。
内容は、お客様から「音ゲーの特定の箇所でコンボが途切れるから、筐体（ゲーム機）のメンテナンスをしてほしい」という要望があった際、担当したアルバイトスタッフが、そのお客様の目の前で実際にその箇所をプレイし、問題なくフルコンボ（連続して正しい操作を成功させること）を達成して見せた、というものです。お客様はそれを見て「もういいです」と言って立ち去られたそうです。この出来事に対し、ゲームセンターの運営者（店長と思われる）は、そのアルバイトスタッフを厳しく𠮟りつけた、というツイートが元になっています。
この店長の対応について、インターネット上では「何が悪いの？」と疑問に思う声と、「バイトの対応には問題があった」とする声に意見が分かれています。
まず、「何が悪いの？」という意見の背景には、エンジニアリングや問題解決の基本的な考え方があります。システムや機器に不具合があるという報告を受けた場合、まず最初に行うべきことは「再現確認」です。お客様が報告した現象が実際に発生するかどうかを自分たちでも試してみることで、本当に機器に問題があるのか、それとも別の要因（例えばお客様の操作ミスやゲームの仕様など）によるものなのかを切り分けることができます。今回のケースでは、お客様の「コンボが外れる」という報告に対して、アルバイトがプレイしてフルコンボできたということは、「少なくともその時点では、筐体にはコンボが外れるような不具合は見られなかった」という再現確認が取れたことになります。トラブルシューティングの観点からは、非常に真っ当で論理的なアプローチと言えます。そのため、技術的な視点を持つ人からは「なぜ正しい確認をしたのに怒られるのか分からない」という意見が多く出ています。
一方で、「バイトの対応には問題があった」という意見の背景には、顧客対応やビジネス的な視点があります。お客様は「コンボが外れる」という不具合を訴えています。その原因がたとえお客様の操作ミスだったとしても、お客様にとっては真剣な困りごとです。そのお客様の目の前で完璧なプレイを見せるという行為は、お客様に「お前の腕が悪いだけだろ」と突きつけるように見えてしまう可能性があります。これではお客様は恥ずかしく感じたり、不快な気持ちになったりして、二度と店に来なくなるかもしれません。ゲームセンターは、お客様がお金を払ってゲームをプレイしてくれることで成り立っています。技術的に正しくても、お客様の気持ちを害してしまい、結果としてお客様が離れてしまうような対応は、商売という観点からは適切ではない、という考え方です。「お客様を不快にさせないように、うまく言葉を選んだり、形だけでもメンテナンスを約束したりするべきだった」という意見が見られました。
この事例から新人エンジニアが学べることはいくつかあります。一つは、技術的な正しさや論理的なアプローチは非常に重要ですが、それだけでは全てがうまくいかない場面もあるということです。特に、お客様や他の関係者と接する際には、相手の感情や立場、求めていること（今回は「不具合を直してほしい」という技術的な要望と、「うまくプレイできない」という感情的な苛立ちの両方があったかもしれません）を理解しようと努め、コミュニケーションの方法を工夫することが求められます。トラブルシューティングの再現確認は重要ですが、それをどのように相手に伝えるか、あるいは伝えるべきでない場面もある、といった、技術以外の「立ち回り」や「配慮」も仕事を進める上で大切になる場合がある、という示唆が得られます。このケースは、技術的な正確さを追求する姿勢と、ビジネス的な顧客満足度や人間関係を重視する姿勢が対立した興味深い事例と言えるでしょう。
引用元: https://togetter.com/li/2543642
VOICEVOX:春日部つむぎ