株式会社ずんだもん技術室AI放送局 podcast 20250422
内容紹介
Build a location-aware agent using Amazon Bedrock Agents and Foursquare APIs Amazon Web Services、Local LLM inference - Amir Zohrenejad - Medium、128GB搭載M4 Max MacBook ProでオープンLLM「Gemma 3」をローカル実行してみた話、慶応大学のAI対策が面白い PDFに透明度100で見えない文書を埋め込みAIに読み込ませると誤回答する仕組みに
出演者
関連リンク
この記事は、Amazon Bedrock AgentsとFoursquare APIを使って、ユーザーの位置情報に基づいた賢いAIエージェントを構築する方法について解説しています。
パーソナル化された体験を提供するために、ユーザーの好みだけでなく、場所や天気といった状況も考慮することが重要です。例えば、晴れた日には公園、雨の日にはカフェといった具合に、状況に合わせたおすすめができれば、ユーザーはより満足するでしょう。このような位置情報を考慮したレコメンデーションを実現するために、Amazon Bedrock AgentsとFoursquare APIを連携させるアプローチが紹介されています。
Amazon Bedrockは、様々な高性能なAIモデルをAPI経由で利用できるAWSのサービスです。インフラ管理なしに生成AIアプリケーションを開発できます。 Amazon Bedrock Agentsは、Bedrockの機能の一つで、AIエージェントを自律的に動作させることができます。これらのエージェントは、ユーザーの複雑なリクエストを理解し、必要なステップに分解して実行できます。特に、会社の持つAPIやデータソースと連携させることで、定型的な業務などを自動化させることが可能です。プロンプトエンジニアリングやメモリ管理などを自動で行ってくれるため、比較的容易に設定できます。
一方、Foursquare Places APIは、正確な位置情報インテリジェンスを提供する外部サービスです。GeoTagging APIで緯度経度から場所を特定したり、Place Search & Data APIで場所のカテゴリや属性、営業時間などで絞り込んで検索したりできます。写真やレビュー、人気度といった詳細な情報も取得可能です。
これらの技術を組み合わせることで、ユーザーが今いる場所や天気といったコンテキストを理解し、それに合わせた関連性の高い、タイムリーな情報を提供できるAIエージェントを作ることができます。記事では、Amazon Bedrock AgentがFoursquare APIと天気APIを呼び出すアーキテクチャが示されており、ユーザーが近くの公園を探したり、公園周辺のテイクアウト可能なレストランを探したりするデモ例が紹介されています。
この位置情報認識エージェントを構築するためのソースコードはGitHubリポジトリで公開されており、必要な環境変数を設定し、依存関係をインストールすれば試すことができます。
開発のベストプラクティスとしては、テストデータセットを用意してエージェントの応答を検証することや、Amazon Bedrock Guardrailsを使って不適切な入力を防ぐ対策を行うことが推奨されています。
このように、Amazon Bedrock Agentsと外部APIを連携させることで、ユーザーの状況に応じたパーソナルな応答ができるAIエージェントを構築し、より優れたユーザー体験を提供できる可能性が示されています。
引用元: https://aws.amazon.com/blogs/machine-learning/build-a-location-aware-agent-using-amazon-bedrock-agents-and-foursquare-apis/
この記事は、LLM（大規模言語モデル）をインターネット上のクラウドサービスではなく、自分のPCやスマホといった「ローカル環境」で動かす技術の現状と、まだ実用化に向けた課題について解説しています。
なぜ、わざわざLLMをローカルで動かしたいのでしょうか？その主な理由はいくつかあります。一つはコストの削減です。クラウドでLLMを使うと利用料がかかりますが、ローカルなら追加費用は不要です。次にプライバシーの向上です。機密性の高い情報を外部のサーバーに送らずに処理できるため、情報漏洩のリスクを減らせます。また、処理速度の向上も期待できます。ネットワークの遅延がないため、特に最初の応答が速くなる可能性があります。さらに、オフラインでも利用できるようになる点も大きなメリットです。例えば、スマートフォンの顔認証機能はローカルでの画像処理（推論）の良い例で、高速性、オフライン性、プライバシーが重要だからこそローカルで行われています。
この記事の著者は、Macbook Pro（M2チップ搭載）を使って、いくつか代表的なローカル推論のためのフレームワーク（プログラムの枠組み）を試しています。具体的には、C/C++で書かれた高速なllama.cpp、それを使いやすくしたOllama、そしてブラウザ上で動くWebLLMです。これらを使って、量子化（モデルを軽量化する技術）された比較的小さな（7Bサイズの）LLMを動かし、性能を測りました。クラウドのOpenAIの小さなモデルとも比較しています。
性能評価では、「最初の単語が出てくるまでの時間（TTFT）」と「1秒間に生成できる単語数（TPS）」を計測しました。結果として、llama.cppとOllamaはTTFTが非常に速く、応答までの待機時間が短いことが分かりました。TPSもこの2つは同程度でした。WebLLMはどちらの指標でも他のフレームワークより遅めでした。クラウドのOpenAIモデルと比較すると、ローカルで動かした小型モデルはTPSで劣る結果でしたが、それでも実用的なレベルの速度は出ていました。
しかし、性能面以外に、ローカルLLMにはまだ開発者が取り組むべき課題があります。最も大きな課題は、モデルの選定と配布です。ローカル環境のリソース（メモリや計算能力）は限られているため、使うタスクに最適な、小さく効率化されたモデルを見つける必要があります。ところが、世の中にはたくさんのモデルがあり、どれを選べば良いか迷いやすいのが現状です。また、選んだモデルのファイルサイズが大きい（数GB以上）ことが多く、ユーザーがアプリを使い始める前にモデルをダウンロード・ロードするのに数分かかることもあります。これは、ユーザーにとって不便で、アプリの最初の体験を損なってしまいます。
結論として、ローカルLLM推論は技術的には可能になり、性能も上がってきていますが、実用的なアプリケーションとして広く普及するには、開発者が目的のモデルを簡単に見つけ、ユーザーがモデルのダウンロードや実行を意識せずに済むような、もっと使いやすい開発ツールや配布の仕組みが必要だと筆者は述べています。将来的には、クラウドとローカルのLLMがうまく連携し、それぞれの利点を活かす形での普及が期待されます。
（992文字）
引用元: https://medium.com/@aazo11/local-llm-inference-897a06cc17a2
この記事は、128GBもの大容量メモリを搭載したM4 Max MacBook Proを使って、Googleの最新オープンな大規模言語モデル（LLM）「Gemma 3」を自分のPC（ローカル環境）で動かしてみた体験談です。API利用料やプライバシーを気にせず、手元でAIを自由に動かしたいという思いから、高性能なMacBook Proを購入し、Gemma 3のローカル実行に挑戦しています。
Gemma 3はテキストだけでなく画像なども扱える「マルチモーダル」に対応しており、特に大きな特徴は非常に長い文脈（コンテキストウィンドウ）を扱えることです。この記事では、Gemma 3の中でもサイズの異なる12B（120億パラメータ）モデルと最大の27B（270億パラメータ）モデルを試しています。
ローカルで動かすための準備は、Open WebUIやllama.cppベースのツールを使えば比較的簡単だったとのこと。M4 Maxチップと128GBメモリ、そしてAppleのMetal技術を使うことで、27Bのような大きなモデルも実用的な速度で動かせました。
実際に試したところ、面白い発見がありました。まず、夏目漱石の小説『吾輩は猫である』の要約をGemma3-12Bにお願いしたところ、内容はそれなりでしたが、なんと作者を芥川龍之介と間違えてしまいました。これは「ハルシネーション（AIが事実と異なることを生成すること）」と呼ばれる現象で、比較的小さなモデルでは知識や理解が不十分な場合があることを示しています。
次に、同じタスクをより大きなGemma3-27Bで試したところ、今度は正確な要約が返ってきました。この体験から、モデルサイズが大きいほど性能が向上することを実感できたそうです。27Bモデルは日本語の長文処理も安定しており、文脈をしっかり保ってくれます。
また、Gemma3-27Bの最大128kトークンという長いコンテキストウィンドウのすごさも体験しました。1万字を超える短編小説を丸ごと入力してテーマを尋ねたところ、全体の構造を理解した深い回答が得られ、まるでPC上で膨大な情報を扱えるAIがいるかのようだと感じたそうです。これは、たくさんのドキュメントを読ませて要約させたり、大量のコードを解析させたりといった、ローカルでの開発作業にも役立つ可能性を示しています。
さらに、Gemma 3の画像認識能力も試しました。画像を入力してその説明を求めたところ、実用レベルの応答があり、ローカルで画像も扱えるマルチモーダルAIの可能性を感じました。ただし、ローカルで画像を使う場合は、モデルを起動するディレクトリに画像ファイルを置くといった少し注意すべき点もあったようです。
高性能なMacBook Proについて、筆者は512GBメモリ搭載のMac Studio (M3 Ultra) も話題になっていることに触れつつ、数千億パラメータのような超巨大モデルを一台のPCで動かすのは計算能力的に現実的ではないと述べています。Gemma3-27Bくらいのモデルが、現在のPCで動かすには性能と負荷のバランスが良い「現実的な上限」だと考えているようです。
最後に、M4 Max MacBook Pro (128GB) は高価ではあるものの、開発作業だけでなく巨大LLMも動かせるその汎用性と性能は価格に見合う価値があり、特にApple Siliconの「ユニファイドメモリ」（CPUとGPUでメモリを共有する仕組み）が大容量を実現している点を評価しています。API料金やプライバシーを気にせずローカルでAIを試せる安心感は大きく、AI活用を本気でやりたいエンジニアにとって、メモリをたくさん積んだMacは有力な選択肢だと結んでいます。
この記事は、高性能なPCとオープンなLLMを使うことで、手元で高度なAI環境を構築できる時代が来ていることを示唆しており、ローカルAIの世界に興味があるエンジニアへの刺激となる内容です。
引用元: https://note.com/cor_instrument/n/n6d2bc4db9175
慶應義塾大学の授業で、PDF資料に一風変わったAI対策が施されていたと話題になっています。これは、学生が課題を提出する際に安易に生成AIに頼りすぎることを防ぎ、AIの特性や限界を理解してもらうための教育的な工夫として注目されています。
具体的には、配布されたPDF資料に、人間が見ても分からないように透明度100%（完全に透明）にしたテキストが大量に埋め込まれていました。この隠されたテキストには、本来の授業内容とは全く関係のない情報や、AIが誤った要約をするように誘導するような内容が含まれていたようです。
生成AIの多くは、PDFなどのドキュメントを読み込む際に、テキストデータとして処理します。このとき、文字の色や透明度といった見た目の情報は考慮されず、そこに書かれているテキストそのものを抽出してしまいます。そのため、AIにこのPDFを読み込ませて要約させると、透明で見えないはずの無関係なテキストまで含めて処理してしまい、元の内容とは全く異なる、おかしな要約結果が出てしまうという仕組みです。
この対策の面白い点は、単に「生成AIを使うな」と禁止するのではなく、AIを課題作成に利用した場合にどのような問題が起こりうるかを、学生自身に体験させる形になっていることです。「課題は自分なりの言葉で記述する」という指示と組み合わせることで、AIが生成した答えをそのまま提出しても適切な評価が得られないことを示唆し、AIの出力内容を鵜呑みにせず、自分で検証し、適切に利用することの重要性を教えています。
この事例は、AIがどのように情報を読み取るか、そしてその特性を理解した上でどのように付き合っていくべきかという、エンジニアにとっても非常に重要な学びを示唆しています。最新技術であるAIも万能ではなく、その動作原理を知り、限界を踏まえて賢く活用していく姿勢が求められていると言えるでしょう。
引用元: https://togetter.com/li/2541260
（株式会社ずんだもんは架空の登場組織です）