株式会社ずんだもん技術室AI放送局

株式会社ずんだもん技術室AI放送局
  • 0.0 (0)
  • TECHNOLOGY
  • UPDATED DAILY

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

  1. 私立ずんだもん女学園放送部 podcast 20251121

    1D AGO

    私立ずんだもん女学園放送部 podcast 20251121

    youtube版(スライド付き) 関連リンク 量子技術でDeepSeekを55%小型化、「検閲解除」にも成功 スペインのMultiverse Computing社が、AIモデル「DeepSeek R1」を改良し、「DeepSeek R1 Slim」を開発したという興味深いニュースが届きました。この新しいモデルは、量子物理学からヒントを得た特別な技術を使うことで、元のDeepSeek R1とほぼ同じ性能を保ちながら、なんとサイズを55%も小型化することに成功したそうです。 この技術のもう一つの大きなポイントは、DeepSeek R1に元々組み込まれていた「検閲機能」を取り除いたと主張している点です。中国では、AI企業が開発するモデルに、国の法律や「社会主義的価値観」に反する内容を出力させないための検閲機能を組み込むことが義務付けられています。そのため、たとえば「天安門事件」や「くまのプーさん」（習近平国家主席を揶揄するミームとして知られる）といった政治的に敏感な話題について質問すると、AIは回答を拒否したり、特定の情報に偏った回答をしたりすることがあります。 Multiverse Computing社は、この小型化と検閲除去のために「テンソルネットワーク」という数学的な手法を採用しました。これは、AIモデルの複雑な内部構造を、量子物理学の考え方を使って効率的に表現・操作する技術です。例えるなら、巨大なデータのかたまりを、無駄なく整理された地図のようにすることで、モデルのサイズを劇的に小さくできるだけでなく、特定の情報（例えば検閲に関わる部分）をピンポイントで特定し、除去できるようになるイメージです。 実際に、中国で制限される質問（約25種類）を使って検証したところ、改良されたモデルは、元のDeepSeek R1が検閲によって回答を制限するような内容に対しても、西側の一般的なAIモデルと同等に事実に基づいた回答を生成できたと報告されています。 この技術は、大規模言語モデル（LLM）の世界に大きな影響を与える可能性があります。現在、高性能なLLMを動かすには、大量のGPU（画像処理装置）と膨大な電力が必要で、コストもエネルギー消費も大きいです。しかし、今回の研究のようにモデルを大幅に圧縮できれば、より少ないリソースでLLMを動かせるようになり、運用コストやエネルギー消費の削減につながります。さらに、検閲だけでなく、AIが持つ可能性のある「バイアス」（特定の情報への偏り）を取り除いたり、特定の専門知識を効率よくAIに学習させたりする応用も期待されています。 ただし、専門家からは、中国政府の検閲システムは非常に複雑で動的なため、少数の質問への対応だけで検閲を完全に「除去」できたと断言するのは難しい、という慎重な意見も出ています。 この研究は、AIの効率化、カスタマイズの可能性、そしてAIと社会・倫理的な問題がどのように交差するかについて、私たちエンジニアが深く考えるきっかけを与えてくれるでしょう。 引用元: https://www.technologyreview.jp/s/372724/quantum-physicists-have-shrunk-and-de-censored-deepseek-r1/ LLM で使われる位置情報のベクトル化について調べてみる この記事では、ChatGPTのような大規模言語モデル（LLM）の基盤技術であるTransformerモデルが、文章中の単語の「位置」をどのように扱っているか、そのための「位置エンコーディング」という技術について、様々な手法を分かりやすく解説しています。 Transformerモデルの根幹技術である「自己注意機構」は、単語同士の関係性を計算しますが、そのままでは単語の順序や位置を考慮できません。例えば、「猫が犬を追いかける」と「犬が猫を追いかける」では意味が全く異なりますよね。この問題を解決するために、単語のベクトルに位置情報を加えることで、単語の並び順も考慮できるようになります。 主要な位置エンコーディングの手法は以下の通りです。 絶対位置エンコーディング (Absolute Position Encoding): Transformerの元論文で使われた基本的な手法です。文の先頭から何番目の単語かという「絶対的な位置」を、数学的な関数（三角関数）を使ってベクトルで表現し、単語の埋め込みに足し合わせます。シンプルですが、非常に長い文章の場合、学習データに登場しないような遠い位置の単語が出てくることで、性能が落ちる場合があります。 相対位置表現 (Relative Position Representation): これは、注目している単語から他の単語が「どれくらい離れているか」という「相対的な位置」をベクトルで表現し、自己注意機構の計算時に利用します。絶対位置に比べて長文でも性能が落ちにくいとされていますが、位置を表すための追加のパラメータが必要になることがあります。 Rotary Position Embedding (RoPE): 現在の多くのLLM（LlamaやGPT-NeoXなど）で採用されている主流の手法です。単語のベクトルをその位置に応じて「回転」させることで、絶対位置と相対位置の両方の情報を表現します。追加のパラメータなしで、特に長文処理において高い性能を発揮できるのが大きな特徴です。 Attention with Linear Biases (ALiBi): これは非常にシンプルなアイデアで、自己注意機構の計算結果（注意スコア）に「線形のバイアス」を足し合わせるだけで位置情報を表現します。追加のパラメータも不要で、単純な仕組みながら長文に対して効果的なことが示されています。 No Positional Encoding (NoPE): 驚くことに、明示的な位置情報を使わない手法もあります。LLMの自己注意機構の特性（Causal Attentionなど、前の単語しか見られない制約）が、暗黙的に位置情報を与えるため、ある程度の性能を出せることが示されています。 Wavelet-based Positional Representation (WPR): 比較的新しい手法で、信号処理で使われる「ウェーブレット変換」という技術を用いて位置を表現します。RoPEよりも柔軟に位置情報を扱え、長文処理でさらに高い性能を発揮できる可能性があり、今後のLLMで採用されるかもしれません。 これらの位置エンコーディングの工夫は、LLMが長い文章を正確に理解し、より自然な文章を生成する上で非常に重要な役割を担っています。特に、最近のLLMは扱う文章がどんどん長くなってきているので、この分野の技術進化は、モデルの性能向上に直結すると言えるでしょう。 引用元: https://zenn.dev/kawara_y/articles/27f69346c851f7 Early experiments in accelerating science with GPT-5 OpenAIは、最新のAIモデル「GPT-5」が科学研究をどのように加速させるかについて、初期実験の結果をまとめた論文を発表しました。科学は私たちの生活のあらゆる面に影響を与えますが、新しい発見やイノベーションの実現には時間がかかり、これが社会全体の課題とされています。GPT-5は、新しいアイデアの創出や、アイデアから具体的な結果に至るまでの時間を短縮することで、科学の進歩を加速し、社会全体に大きな利益をもたらす可能性を秘めています。 この研究は、著名な大学や研究機関との共同で行われました。GPT-5は、数学、物理学、生物学、計算機科学、天文学、材料科学といった幅広い分野で、研究者が新しい発見をするのを支援しています。 具体的な成功事例をいくつかご紹介します。 生物学: 数ヶ月かかっていた免疫細胞の変化の原因特定を、GPT-5がわずか数分で推測し、その検証のための実験まで提案しました。これにより、病気の理解や治療法開発が加速するかもしれません。 数学: 数十年もの間未解決だったポール・エルデシュの問題に対し、GPT-5が証明の最終ステップとなる画期的なアイデアを提供しました。 アルゴリズムと最適化: ロボット工学などで使われる意思決定手法に、人々が気づかなかった問題点があることをGPT-5が発見し、最適化という数学分野の古典的な結果を改善しました。 OpenAI for Scienceは、研究者がより多くのアイデアを探求し、仮説検証を加速し、通常では多くの時間を要する発見を可能にすることを目指しています。これは、シミュレーションツールやデータベースといった専門的な科学ツールと、さまざまな分野のアイデアを結びつける能力を持つ基盤モデル（GPT-5のような大規模言語モデル）を組み合わせることで実現しようとしています。 ただし、GPT-5は自律的に研究を進めるものではありません。最も有意義な進歩は、科学者が質問を設定し、方法を選び、アイデアを批判し、結果を検証する「人間とAIの

  2. 2D AGO

    株式会社ずんだもん技術室AI放送局 podcast 20251120

    youtube版(スライド付き) 関連リンク Building more with GPT-5.1-Codex-Max 日本の新人エンジニアの皆さん、こんにちは！OpenAIから、皆さんの開発を大きく助けてくれる新しいAIエージェント型コーディングモデル「GPT-5.1-Codex-Max」が発表されました。これは、これまでのAIモデルの限界を超え、より賢く、速く、そして効率的にコード開発をサポートすることを目指しています。 何が新しいの？ このモデルの最大の進化は、「Compaction（コンパクション）」という新しい技術によって、「長時間の詳細な作業」をこなせるようになった点です。これまでのAIは、一度に扱える情報量（コンテキストウィンドウ）に限りがあり、長い時間のかかる複雑なタスクでは途中で「あれ？何してたっけ？」となってしまうことがありました。 しかし、GPT-5.1-Codex-Maxは、まるで人間がメモを取りながら考えるように、必要に応じて過去の情報を整理・圧縮することで、何百万ものトークンを扱う大規模なプロジェクトのリファクタリングや、数時間にわたるデバッグセッション、さらには自律的なエージェントループまで、途切れることなく作業を続けられるようになりました。社内評価では24時間以上も独立して作業し、テストの失敗修正までこなした例もあるそうです。 開発体験はどう変わる？ 高速・高効率・低コスト: より少ないトークンで高い性能を発揮するため、開発コストの削減にも繋がります。例えば、高品質なフロントエンドデザインを、以前より低いコストで作成できるようになりました。 実践的な開発作業に強い: PR（プルリクエスト）の作成、コードレビュー、フロントエンドコーディング、Q&Aなど、実際のソフトウェア開発現場で必要とされるタスクに特化して学習されています。なんと、Windows環境での動作にも対応しました。 利用方法と注意点 GPT-5.1-Codex-Maxは、現在、CodexのCLI（コマンドラインインターフェース）、IDE（統合開発環境）拡張機能、クラウド、コードレビューなどで利用可能です。APIアクセスも近日提供予定です。 ただし、AIエージェントの利用にはいくつかの注意点があります。 人間による確認の重要性: AIが生成したコードやレビュー結果は、最終的には人間が確認し、承認することが非常に重要です。AIはあくまで強力な「共同作業者」であり、人間の「代替」ではありません。 セキュリティ: Codexはデフォルトで安全なサンドボックス環境で動作しますが、インターネットアクセスなどを有効にする場合は、プロンプトインジェクションなどのリスクに注意が必要です。 OpenAI社内では、すでにエンジニアの95%が週にCodexを利用し、プルリクエストの提出数が約70%も増加したとのこと。GPT-5.1-Codex-Maxは、皆さんの開発生産性を劇的に向上させる可能性を秘めています。この新しいツールをぜひ活用して、素晴らしいものを生み出してください！ 引用元: https://openai.com/index/gpt-5-1-codex-max LLMで業務ワークフローを自動生成・最適化する! 〜ワークフロー自動生成・最適化の取り組みについて〜 LLM（大規模言語モデル）は様々なタスクに利用できますが、複数のステップを組み合わせるような複雑な業務を丸ごと任せるのは難しい場合があります。そこで注目されているのが、LLMとプログラミングコード（Pythonなど）を組み合わせて、複雑なタスクを効率的に処理する「AIワークフロー」です。例えば、「文章を要約する」→「情報を抽出する」→「整形する」といった流れを自動化します。 しかし、このAIワークフローを作るには、「どんなステップを組み合わせるか」「各ステップでどんな指示（プロンプト）を出すか」といった設計に、多くの時間と手間がかかるのが課題でした。また、LLMのアップデートや扱うデータが変わると、ワークフローを修正する必要があり、これが運用上の負担となっていました。 LayerXでは、これらの課題を解決するために、AIワークフローを自動で生成・最適化する技術に取り組んでいます。この技術は、Generator（LLMで新しいワークフローのアイデアを出す）、Executor（アイデアを試す）、Evaluator（試した結果を評価する）、Memory（過去の経験から学習する）という4つの仕組みを連携させます。これにより、まるで人間が試行錯誤するように、AIが自らワークフローの構造やプロンプト、コードを学習し、より良いものに改善していくことができます。約5〜7回の試行で、高精度なワークフローが見つかったそうです。 具体的な成功事例として、300ページを超えるプロジェクト完了報告書から、工数やコストなど48個の複雑なデータを抽出・計算するタスクが紹介されています。このタスクでは、以下の6つのステップからなるワークフローが自動で生成されました。 1ページずつテキスト化（Python）: PDFから各ページをテキストデータに変換。 重要ページを判定（LLM）: 300ページの中から、必要な情報が含まれる「重要ページ」をLLMが判定。これを30ページ程度に絞り込み、LLMが一度に処理できる情報量に調整する工夫が自動で発見されました。 重要ページを選択・結合（Python）: 判定された重要ページを結合し、次のステップへ渡します。 データを抽出（LLM）: 結合されたテキストから、LLMが数値を抽出します。ここでは「計算は禁止」と明確に指示し、LLMには情報の「読み取り」に集中させます。 合計値を計算（Python）: 抽出された数値を使って、Pythonコードで正確な計算（合計値、差異、密度など）を行います。 単位を正規化（Python）: 最終的なデータ形式に合わせて、単位などを調整します。 このワークフローは、大規模なデータ処理においてLLMの制約を克服する「チャンキング戦略（必要な部分だけを切り出す工夫）」や、LLMとPythonがそれぞれの得意な役割（LLMは「意味理解・判断」、Pythonは「正確な計算・データ整形」）を分担する最適な方法をAIが自動で発見した点が画期的です。この取り組みにより、訓練データでは約90%の精度を達成しました。 今後も、より複雑なタスクへの適用や精度の向上が期待されており、AIを活用した業務効率化の大きな可能性を示しています。 引用元: https://tech.layerx.co.jp/entry/2025/11/19/133143 仕様駆動開発の理想と現実、そして向き合い方 AIを活用した開発が広がる中、感覚的にコードを書く「Vibe Coding」から脱却し、より確実な成果を出すための「仕様駆動開発（Spec-Driven Development: SDD）」について、その理想と現実、そして現場での向き合い方が解説されています。新人エンジニアの方にも理解しやすいように、要点をまとめました。 1. 仕様駆動開発（SDD）とは？ SDDは、AIが直接コードを生成できるレベルまで詳細に、かつ構造化された「Spec（仕様書）」を作成し、それを中心に開発を進めるアプローチです。これまでの開発では「コード」が共通言語でしたが、SDDでは「自然言語」で書かれたSpecがその役割を担います。これにより、人間はSpecの承認やレビューが主な役割となり、AIが開発の主体となる新しいスタイルが期待されています。 2. SDDの理想とメリット SDDが理想通りに機能すれば、以下のような大きなメリットがあります。 手戻りの削減: 事前に明確なSpecがあるため、実装段階での認識のズレが減ります。 設計レビューの負担軽減: Specが構造化されているため、設計内容の理解が容易になります。 並行開発の促進: 各機能のSpecが独立していることで、複数のチームやエンジニアが並行して開発を進めやすくなります。 品質とスピードの向上: Spec作成からレビュー、実装、テスト、フィードバックのサイクルがAIによって高速化され、高品質なソフトウェアを迅速に顧客に届けられるようになります。 「検証可能性」と「フィードバックループ」: Specの振る舞いが自動テストと結びつき、実装の正確性が検証されます。また、Specは一度作ったら終わりではなく、開発を通じて改善されていくものと捉えられています。 3. SDDの現実と課題 しかし、SDDはまだ進化の途中にあり、2025年11月時点ではいくつかの課題も抱えています。 ツールの未成熟: 現在のSDDツールやLLM（大規模言語モデル）の性能は、SDDの理想に完全に追いついていません。 Specの巨大化とレビューの負荷: AIが生成するSpecが大きくなりすぎることがあり、人間

  3. 3D AGO

    株式会社ずんだもん技術室AI放送局 podcast 20251119

    youtube版(スライド付き) 関連リンク Start building with Gemini 3 Googleは、これまでで最もインテリジェントなAIモデル「Gemini 3 Pro」を発表しました。このモデルは、新人エンジニアの方でも、あなたのアイデアをAIを活用したアプリケーションとして実現できる、非常にパワフルなツールです。 Gemini 3 Proは、これまでのモデルを大きく上回る性能を持ち、特にAIの評価基準やコーディングタスクで優れた結果を出しています。AIが自律的に複雑なタスクを処理したり、ゼロからのコーディングもこなしたりする「エージェントワークフロー」において、その真価を発揮します。 開発者は、Google AI Studioや企業向けのVertex AIを通じて、Gemini APIを利用してGemini 3 Proにアクセスできます。これにより、既存の開発プロセスにAIの力を簡単に組み込むことができます。 また、Gemini 3 Proは、開発のあり方を大きく変える可能性を秘めています。 一つは「Agentic coding（エージェントコーディング）」です。これは、AIが自らコードの生成、デバッグ、リファクタリングといった一連の作業を計画し実行する、自律的なコーディングを可能にします。Google Antigravityという新しいエージェント開発プラットフォームを使えば、まるでAIアシスタントと共同作業するように、タスクベースで開発を進められます。エディタ、ターミナル、ブラウザを横断してAIが動くイメージです。 もう一つは「Vibe coding（バイブコーディング）」です。これは、自然言語でアイデアを伝えるだけで、AIがその意図を理解し、インタラクティブなアプリケーションを自動で生成してくれるという画期的なアプローチです。複雑なコーディング知識がなくても、あなたのひらめきを直接アプリの形にできます。Google AI Studioで、たった一つのプロンプト（命令文）からゲームやウェブサイトを開発することも可能です。 さらに、Gemini 3 Proは「マルチモーダル理解」においても進化を遂げています。これは、テキストだけでなく、画像や動画、さらには空間的な情報までを総合的に理解する能力です。例えば、複雑な書類の内容を正確に読み解いたり、動画の中の動きを高速に認識したり、ロボットや自動運転車の空間認識能力を高めたりできます。画面の要素やユーザーの操作意図を理解し、コンピュータ操作を自動化するような「Visual Computer」といった新しい体験も可能になります。 Gemini 3 Proは、開発者がAIを活用して、これまでにないものを作り出すための強力な基盤となるでしょう。既存のツールやワークフローにシームレスに組み込まれ、あなたの創造性を最大限に引き出すことを目指しています。ぜひGoogle AI StudioでGemini 3 Proを試し、AIとの新しい開発体験を始めてみてください。 引用元: https://blog.google/technology/developers/gemini-3-developers/ Solving a Million-Step LLM Task with Zero Errors この論文は、大規模言語モデル（LLM）が抱える「長大なタスクをエラーなく実行できない」という課題に対し、画期的な解決策を提示しています。これまでのLLMは、思考やツールの利用で素晴らしい進歩を見せていますが、人間や組織が行うような何百、何千ものステップを要する複雑なプロセスになると、どこかで間違いが生じ、途中で処理が破綻してしまうことが課題でした。例えば、有名な「ハノイの塔」のような古典的な問題解決タスクのベンチマーク実験では、わずか数百ステップで処理が立ち行かなくなることが示されています。 本論文で紹介されている「MAKER」というシステムは、この問題を克服し、なんと100万ステップを超えるLLMタスクを「エラーゼロ」で成功させることに世界で初めて成功しました。これは、理論上さらに大規模なタスクにも対応できる可能性を秘めています。 MAKERのアプローチの鍵は、二つの革新的な要素にあります。 一つ目は、「極端なタスク分解（extreme decomposition）」です。これは、非常に複雑な一つの大きなタスクを、それぞれが非常にシンプルで実行しやすい「マイクロエージェント」と呼ばれる専門の小さなAIプログラムに割り振られる、極めて細かなサブタスクへと徹底的に分解する手法です。これにより、各ステップでの複雑性を大幅に低減します。 二つ目は、「効率的なマルチエージェント投票スキームによるエラー訂正」です。タスクが非常に細かく部品化（モジュール性）されているため、各マイクロエージェントの処理ステップで発生する可能性のあるエラーを、複数のエージェントによる多数決のような投票メカニズムで効率的に検出し、即座に修正することができます。 この「極端なタスク分解」と「逐次的なエラー訂正」の組み合わせにより、これまでのLLMでは不可能だった大規模なスケールでのタスク実行が可能になりました。この研究結果は、今後のLLMの進化が、個々のモデル性能の改善だけでなく、「Massively Decomposed Agentic Processes（MDAPs）」、つまり、大規模に分解されたエージェント群による協調的なプロセス設計によって、組織や社会レベルの複雑な課題を効率的に解決する道を開く可能性を示唆しています。新人エンジニアの皆さんにとって、AIが現実世界の問題を解決するためにどのように進化していくかを知る上で、非常に示唆に富む内容と言えるでしょう。 引用元: https://arxiv.org/abs/2511.09030 ReAct 論文と共に読み解く strands-agents/sdk-python の実装 AIエージェント開発が加速する中、エージェントが賢く振る舞うための土台となる技術理解は非常に重要です。この記事では、AIエージェントの基本的な枠組みである「ReAct」論文の解説と、それをAWSが提供するOSSのSDK「strands-agents/sdk-python」がどのように実装しているかを、新人エンジニアの方にも分かりやすく解説しています。 ReAct（Reasoning and Acting）とは？ ReActは、大規模言語モデル（LLM）が複雑なタスクを効率的にこなすためのフレームワークです。これは、人間が何かを考える時に「推論（Reasoning）」と「行動（Acting）」を組み合わせるように、LLMにも同様のプロセスを踏ませることを提案しています。 例えば、料理をする際に「パン生地の作り方を知らないからインターネットで調べよう（推論）」と考え、実際に「インターネットで調べる（行動）」といった一連の流れは、推論と行動が密接に連携していることを示しています。ReActでは、LLMに「思考（Thought）」という言語空間での行動も加え、以下のループでタスクを解決します。 思考（Thought）: 自然言語で計画を立てたり、問題点を分析したりする。 行動（Action）: 外部ツール（Web検索など）を使って情報を収集する。 観測（Observation）: 行動の結果として得られた情報を認識する。 このサイクルを繰り返すことで、LLMはより賢く、正確にタスクを遂行できるようになります。LLMの登場によって、この「思考」を含む広大な言語空間での処理が現実的なものとなりました。 strands-agents/sdk-pythonでのReAct実装 「strands-agents/sdk-python」は、このReActの考え方に基づいてAIエージェントを開発するためのSDKです。エージェントは内部で「Agentic loop」と呼ばれる処理を繰り返しながらタスクを進めます。このループは基本的に以下の流れで構成されています。 LLMによる推論（思考）: エージェントはこれまでの会話や状況から、次に何をすべきかをLLMに推論させます。 ツール実行（行動）: LLMの推論に基づいて、Web検索などの外部ツールを実行します。 結果の受け取り（観測）: ツール実行の結果を受け取り、次の推論の材料とします。 このSDKでは、エージェントがこれまでの「思考・行動・観測」の全ての情報を「Messages」という形で逐次的に保持しています。この履歴をLLMに渡すことで、LLMは過去の経緯を踏まえた上で次に取るべき最適な「思考」や「行動」を決定できるため、タスクを賢く解決できるようになるのです。 例えば、「パン生地の作り方を知りたい」というユーザーの入力に対し、エージェントはまず「ウェブ検索を計画（思考）」し、「ウェブ検索を実行（行動）」、その「結果を受け取り（観測）」ます。そして、その検索結果を元に「情報を整理して回答（思考）」するという流れで、ReActのフレームワークが実現されています。 このように、ReActという理論的な枠組みが、実際のSDKでどのように実装されて

  4. 4D AGO

    株式会社ずんだもん技術室AI放送局 podcast 20251118

    youtube版(スライド付き) 関連リンク Agents 2.0: From Shallow Loops to Deep Agents AIエージェントは、近年非常に注目されている技術です。これまで主流だった「Agent 1.0（シャローエージェント）」は、AIモデルがユーザーの指示を受けてツールを使い、結果を返すというシンプルな仕組みで動いていました。例えば、「東京の天気は？」といった簡単な質問には素早く答えられます。 しかし、「10社の競合を調査して、比較表を作り、戦略レポートをまとめる」といった、何十ものステップが必要で数日かかるような複雑なタスクになると、Agent 1.0には限界がありました。AIモデルの一時的な記憶（コンテキストウィンドウ）がすぐにいっぱいになり、これまでの会話履歴や指示が消えてしまったり、本来の目標を見失ったり、間違った方向に進んで戻れなくなったりすることが多々ありました。まるで、一度にたくさんのことを覚えられない新人さんのように、情報過多で混乱してしまっていたのです。 この課題を解決するために登場したのが、「Deep Agents（Agent 2.0）」という新しい考え方です。Deep Agentsは、単に反応するだけでなく、より能動的に問題を解決するためのアーキテクチャを持っています。その鍵となるのが、以下の4つの柱です。 明示的な計画 (Explicit Planning): AIエージェントが漠然と考えるのではなく、まるでToDoリストを作るように具体的な計画を立て、実行します。途中で何かに失敗しても、計画を見直して修正することで、タスク全体を見失わずに進められます。 階層的な役割分担（サブエージェント） (Hierarchical Delegation): 複雑なタスクを、一つのエージェントが全てこなすのではなく、「司令塔」となるエージェントが、「調査担当」や「プログラミング担当」といった専門の「サブエージェント」に仕事を割り振ります。各サブエージェントは自分の専門分野に集中し、その結果だけを司令塔に報告することで、効率よく役割分担ができます。 永続的な記憶 (Persistent Memory): AIモデルの一時的な記憶だけに頼らず、ファイルやデータベースといった外部の記憶装置に中間結果や重要な情報を保存します。これにより、必要な情報をいつでも取り出せるようになり、記憶の限界を突破します。 詳細な指示（コンテキストエンジニアリング） (Extreme Context Engineering): AIモデルが賢くなったからといって、簡単な指示だけで動くわけではありません。「いつ計画を立てるか」「どんな時にサブエージェントに仕事を任せるか」「ツールの使い方」など、非常に具体的で詳細な指示をAIモデルに与えることで、複雑な行動を精密にコントロールします。 Deep Agentsは、これらの工夫を通じて、AIエージェントが数秒で終わるタスクだけでなく、数時間や数日かかるような、より大規模で複雑な問題にも挑戦できるようになることを目指しています。これは、AIモデル自体の性能向上だけでなく、そのモデルをいかに効果的に設計し、活用するかの「エンジニアリング」の重要性を示唆しています。AIエージェントは、ただの「反応するプログラム」から「能動的に問題を解決するパートナー」へと進化していると言えるでしょう。 引用元: https://www.philschmid.de/agents-2.0-deep-agents Claude Code on the Web を超える!? Codex Cloud の実践テク5選 Web上で動くAIエージェントは、自分のパソコン環境（ローカル環境）と完全に分かれているため、とても便利ですが、使う上での制約もあります。例えば、「どうやって開発を進めるかの計画が立てにくい」「AIが作った設計書の確認が難しい」「ローカル環境との連携がスムーズにいかない」といった悩みを持つエンジニアもいるかもしれません。 この記事では、OpenAIが開発したクラウドベースのAIコーディングエージェント「Codex Cloud」を使うことで、これらの悩みを解決し、効率的に開発を進める実践的な方法が紹介されています。高機能なWeb上のAIエージェント「Devin」は月額500ドルかかる場合がありますが、Codex CloudはChatGPTの有料プランがあれば利用できるため、手軽に始められるのが大きな魅力です。 Codex Cloudは、インターネット上の安全な隔離された環境で動作し、開発を始める前に「実装計画書」を作成してくれる「Planモード」があります。デフォルトでは大まかな計画ですが、後述のテクニックで精度を高められます。 ここからは、Codex Cloudをさらに使いこなすための5つの実践テクニックを紹介します。新人エンジニアの方も、ぜひ活用してみてください。 カスタム指示を設定する: デフォルトでは英語出力になったり、計画書が簡素だったりする問題を、カスタム指示（AIへの具体的な指示）を設定することで解消できます。日本語で回答させたり、計画書の精度を上げたりと、自分好みにカスタマイズすることで、開発体験が格段に向上します。 同時並行モードを活用する: このモードを使うと、同じタスクに対して複数のAIを並行して動かし、異なるアプローチや解決策を同時に生成・比較できます。例えば、最初の段階で4つの異なる大まかな方向性を検討し、その中から最適なものを選んで、さらに詳細な実装パターンを並行して検討するといった使い方ができます。ただし、多くの情報処理（Token消費）が必要になるため、使い過ぎには注意が必要です。 Local上で変更差分をすぐに取り入れる: Codex Cloudで作成・変更されたファイルを、素早く自分のローカル環境に取り込む機能があります。「git apply をコピーする」ボタンを使えば、プルリクエスト（PR）を作成する手間なく、変更を適用できるため、開発の連携がスムーズになります。 Plan作成と実装を分ける: Planモードで作成された実装計画を、すぐに「タスクを開始」ボタンで実行するのは、場合によっては避けた方が良いとされています。特に複数のタスクがある場合、それぞれが個別の変更として扱われ、一つのPRにまとめにくくなるためです。計画をしっかり立ててから、新しいスレッドでまとめて実装を依頼する方が、変更管理がしやすくなります。 機能要件を整理した上で、並行開発を行う: AIに良いアウトプットを出してもらうためには、事前に「何を作りたいのか」という機能要件を明確に整理することが非常に重要です。要件が曖昧なまま並行開発を行っても、質の低い結果しか得られません。まず一つのスレッドで必要な要件をしっかり整理し、その上で新しいスレッドで並行開発を行うことで、各実装の精度が高まり、比較検討もしやすくなります。 これらの実践テクニックを活用することで、Codex CloudはWeb上での開発をより効率的かつ高精度に進める強力なツールになります。ぜひ、これらの方法を試して、日々の開発に役立ててみてください。 引用元: https://zenn.dev/sunagaku/articles/codex-cloud-5-tips 自宅のRTX3060で小さなLLMを自作してみた この記事では、個人所有のPC（NVIDIA GeForce RTX3060）を使って、独自の小規模な大規模言語モデル（LLM）を開発し、事前学習を行った事例が紹介されています。新人エンジニアの方でも「自分のPCでどこまでできるんだろう？」という疑問へのヒントになるでしょう。 まず、LLMの学習データとして、前処理済みの「青空文庫」データセットから、現代の日本語に当たる「新字新仮名」に絞り込んだ約1万件の作品が利用されました。これにより、日本語の古典的な表現ではなく、より身近な現代日本語のテキストを学習させることが目的です。 次に、このデータセットに特化した「トークナイザー」を自作しています。トークナイザーは、文章をLLMが理解できる「トークン」という単位に分割する役割を担います。一般的なトークナイザーではなく、青空文庫の日本語表現に最適化するため、「SentencePiece」を使って32,000語彙のunigramモデルを構築。日本語特有の語尾などを細かく分割できるよう工夫し、「となって」「集まっている」といった表現が適切にトークン化できることを確認しています。 モデルのアーキテクチャは、GPT-2をベースに、RTX3060のVRAM（12GB）に収まるよう、パラメータ数を42.1M（4210万）に抑えた小型版を設計しました。具体的には、モデルの層数や埋め込み次元を調整し、学習効率とVRAM消費のバランスを取っています。少ないリソースで学習を安定させるため、バッチサ

  5. 5D AGO

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20251117

    関連リンク Anthropic社の「Code Execution with MCP」が示す未来 ―― ツールコール時代の終焉と、エージェント設計の次 Anthropic社が提唱する「Code Execution with MCP」は、AIエージェントの設計方法を大きく変える新しいアプローチです。これまでの「ツールを直接呼び出す」方式が抱えていた問題を解決し、より効率的で将来性のあるAIエージェントの構築を可能にします。 MCP（Model Context Protocol）は、AIがデータベースや外部サービスなどのツールと連携するための標準化された仕組みで、AIの「USBポート」のようなものです。これにより、様々なAIモデルで共通の方法で外部ツールを利用できるようになります。 しかし、従来のAIエージェント開発では、全てのツール定義や処理の途中経過をAIへの指示（コンテキスト）に詰め込みすぎていました。この方法では、AIが処理する情報量（トークン）が異常に増え、コスト高や処理遅延の原因となっていました。「質問に答えるだけで15万トークンも消費した」という報告もあり、大規模なエージェントシステムでは限界が見えていました。 この問題を解決するため、Anthropic社が提案したのが、「ツールを直接呼ぶのではなく、AIが自分でコードを生成し、そのコードを実行する」という「Code Execution × MCP」のアプローチです。この仕組みでは、AIは以下の手順で動作します。 エージェントは、利用可能なツールの「ファイル構造」だけを把握します。 必要なツールが出てきたら、そのツールのコードファイルを動的に読み込みます。これにより、全てのツール定義をAIに最初から渡す必要がなくなります。 AIは、ユーザーの要求に応じてPythonやTypeScriptなどのコードを生成します。 生成されたコード内で、MCPで標準化されたツールを「コード部品」のようにimportして利用します。 データの加工や繰り返し処理といった中間的な作業は、AIが書いたコード側で完結させます。 AIには最終的な結果だけが伝えられ、AIは「何をすべきか」という意思決定に集中します。 この新しい方法により、AIに渡す情報量が劇的に削減され、実際の運用コストや応答速度が大幅に改善されます（最大98.7%のトークン削減例も報告されています）。 このアプローチが「次の標準」となる理由は、まず、AIエージェントが複雑化しても、必要な情報だけを動的に読み込むため、システムが破綻しにくい点です。次に、多様なAIモデルに対応できる「コードファイル」という共通形式でツールを扱えるため、特定のモデルに依存しない汎用的な開発が可能です。そして、AI（意思決定）、MCP（接続の標準化）、コード（具体的な処理と制御）という明確な役割分担がなされ、大規模なAIエージェントの効率的な設計・運用に適しています。 これからAIエージェント開発に携わる新人エンジニアの皆さんは、「コード実行を前提とした設計」を意識することをおすすめします。ツールを個別のコードファイルとして整理し、AIには意思決定を任せることで、効率的で持続可能なAIエージェントを構築できるでしょう。この「ツールコール時代は終わり、エージェントはコードを書く」という変化を理解し、実践することが、これからのAI開発で一歩先を行くための鍵となります。 引用元: https://zenn.dev/hatyibei/articles/6b26d6bd27a9c2 ステートレスなLLMでステートフルなAI agentを作る - YAPC::Fukuoka 2025 この発表は、おしゃべりAIサービス「Cotomo」の開発経験に基づき、ステートレスな大規模言語モデル（LLM）を使って、あたかも記憶を持っているかのように振る舞うステートフルなAIエージェントをどう構築するかについて解説しています。 まず、LLMは基本的に「ステートレス」であり、以前の会話を記憶しません。APIへの各呼び出しは独立しています。しかし、モデル自体が学習データから得た「静的な知識」と、プロンプトとして与えられた「短期的な記憶（コンテキスト）」は利用できます。私たちが普段使うChatGPTのような対話AIは、このステートレスなLLMの内部で会話履歴を管理し、記憶があるかのように見せているのです。 AIエージェントに「記憶」を持たせるには、いくつかの技術的な工夫が必要です。単純に過去の会話履歴をすべてプロンプトに詰め込む方法は、LLMが一度に処理できるテキスト量（コンテキストウィンドウ）に限界があるため、性能の劣化や情報を見失う原因となります。 この課題を解決するため、「RAG（Retrieval-Augmented Generation：検索拡張生成）」と「会話要約」が重要な役割を果たします。 RAGは、ユーザーの入力に関連する情報を外部のデータベースから検索し、その情報をLLMへのプロンプトに含める技術です。これにより、コンテキストを短く保ちつつ、関連性の高い情報をLLMに提供できます。Cotomoでは、テキストを数値のベクトルに変換して意味的な類似度で検索する「Vector Search（ベクトル検索）」を使い、長期的な事実を記憶させています。 会話要約は、過去数ターンの会話内容を別のLLMで要約し、その要約をプロンプトに含めることで、直近の会話の流れをLLMに伝え続ける方法です。これにより、コンテキストウィンドウを節約し、会話全体の状況を把握しやすくなります。ただし、要約には情報が欠落するリスクもあります。 Cotomoではこれらの技術を組み合わせ、記憶システムを進化させてきました。初期バージョン（v1）では抽出された事実を記憶していましたが、会話中の事実と普遍的な事実の区別や情報の更新に課題がありました。次のv2では生の会話データを直接RAGに利用しましたが、ノイズが多くデータ量が増える問題がありました。現在の構想（v3）では、Vector Search専用のデータベースを導入し、会話履歴からノイズを除去した「事実」を抽出し、定期的に記憶を整理・統合する仕組みを目指しています。 AIエージェントが映画「Her」に出てくるような理想的なパートナーになるためには、単なる道具ではなく、人格や内面を持ち、人間を超える知識と記憶力、判断力を備え、自律的に活動する存在になることが必要です。ステートレスなLLMを基盤として、これらの記憶システムを構築し進化させることが、その実現への鍵となります。 引用元: https://speakerdeck.com/gfx/sutetoresunallmdesutetohurunaai-agentwozuo-ru-yapc-fukuoka-2025 Web エンジニアが JavaScript で AI Agent を作る / JSConf JP 2025 sponsor session この発表は、WebエンジニアがJavaScriptを使ってAI Agentを開発することの可能性と魅力について、新人エンジニアにも分かりやすく解説しています。目的は、AIやLLM（大規模言語モデル）をプロダクトに組み込むことへの抵抗感をなくし、そこにある技術的な挑戦にワクワクしてもらうことです。 LLMとAI Agent開発の変化 これまでのAI/機械学習と異なり、現在のLLMは「REST API」のように扱えるようになりました。これは、モデルが非常に大きくなったことで、自分で学習・ホストする代わりに、プロバイダが提供するAPIを通じて利用するのが主流になったためです。JSONを投げたらJSONが返ってくるという、Webエンジニアにとっては見慣れた形式でAIを活用できるようになったため、JavaScriptなどの言語でもAI Agent開発に挑戦しやすくなっています。 AI Agentとは、LLMが自ら考えてツールを使いこなし、タスクを達成するシステムのこと。例えば、何か指示を与えると、AIが「計画→行動→結果確認」というサイクル（Agent Loop）を繰り返しながら、与えられたタスクを完了させようとします。 AI Agent開発における技術的チャレンジとWebエンジニアの強み AI Agent開発には、いくつか特有の難しさがありますが、Webエンジニアの経験が役立つ場面がたくさんあります。 確率的挙動への対応: AIの出力は毎回同じとは限りません。この「確率的挙動」という課題に対し、従来のテストだけでなく、「Observability（可観測性）」や「Evals（評価）」といった手法が重要になります。Langfuseのようなツールを使ってAIの呼び出し履歴やコスト、実行時間を追跡したり、LLM自身にタスクの達成度を評価させる「LLM-as-a-Judge」のようなユニークな評価方法も登場しています。 Webエンジニアの専門性が活きる領域: UI/UX: 長時間かかるAIの処理を、ユーザーが快適に利用できるUI設計。チャットだけでなく、ボタン一つで完了するようなシン

  6. 私立ずんだもん女学園放送部 podcast 20251114

    NOV 13

    私立ずんだもん女学園放送部 podcast 20251114

    youtube版(スライド付き) 関連リンク Let AI do the hard parts of your holiday shopping Googleは、ホリデーシーズンに向けてAIとエージェント技術を駆使した革新的なショッピングツールを発表しました。これにより、買い物の「面倒な部分」をAIが担い、ユーザーはより賢く、ストレスなく商品を見つけられるようになります。日本の新人エンジニアの皆さんにも理解しやすいよう、主要な機能をご紹介します。 検索での対話型AIショッピング： Google検索の「AIモード」が強化され、まるで友達に話すように自然な言葉で欲しいものをAIに伝えられます。「暖かいセーター」といった具体的なリクエストにも対応。AIは「Shopping Graph」（500億以上の商品データベース）から、価格、レビュー、在庫などの最新情報を整理して提示。画像や比較表で分かりやすく表示し、素早い選択を支援します。 Geminiアプリでのショッピング機能拡張： GoogleのAIアシスタント「Gemini」アプリにもショッピング機能が統合されました。買い物のアイデア出しから商品探しまでGeminiがサポート。Shopping Graphからの信頼性の高い商品リストや価格情報などをアプリ内で提供します（米国で提供開始）。 エージェントAIによる近隣店舗の在庫確認： 「欲しい商品が近くの店にあるか知りたい」時、「Let Google Call」機能を使えば、AIがユーザーに代わって近隣店舗に電話し、在庫状況や価格を確認。Googleの「Duplex技術」と最新のGeminiモデルが支え、ユーザーは電話を待つことなく、メールやテキストで結果を受け取れます。米国の一部カテゴリーで順次展開されます。 エージェントAIによる最適な価格での自動購入（Agentic Checkout）： この「agentic checkout」機能は、狙った価格になったら欲しかった商品を自動で購入する仕組みです。ユーザーが商品の詳細と希望価格を設定すると、予算内になった際に通知。対象の販売者の場合、ユーザーの許可を得てGoogleがGoogle Payを使って自動的に商品を購入。最適なタイミングを逃さず賢く買い物が可能です。 これらのAI活用による新しいショッピング体験は、日々の買い物をよりスマートで快適なものに変えるでしょう。忙しいエンジニアの皆さんにとって、時間を節約しつつ賢い選択をするための強力なツールとなりそうです。 引用元: https://blog.google/products/shopping/agentic-checkout-holiday-ai-shopping/ 会話型AIエージェントでFunction Callingを使いこなす！ tacomsのMorixさんが、飲食店向け電話注文受付AIエージェント「Camel AI Call」の開発を通じて得た、LLMのFunction Calling活用術と課題解決策を共有しています。Function Callingは、LLMが外部のシステム（データベースやAPIなど）と連携して、情報を取得したり特定の処理を実行したりするための重要な機能です。例えば、ユーザーの質問に応じて天気情報を取得するツールをLLMが呼び出す、といった使われ方をします。 この機能を使う上で遭遇する主な課題と、その解決策は以下の通りです。 期待するツールをLLMが呼んでくれない場合: 複数のツールがあるときに、ユーザーの発話に対して意図しないツールが呼ばれたり、全く呼ばれなかったりすることがあります。 解決策: LLMに最初に与える「システムプロンプト」で、いつどのツールを呼ぶべきかを具体的に指示します。さらに、ユーザーの新しい発話のたびに、その時点の会話状況や必要なツール呼び出しルールを「動的プロンプト」としてLLMに毎回伝えることで、LLMが状況を忘れずに正確にツールを選べるようになります。 ツール実行後のLLMの動作を制御できない場合: ツールが成功したときは結果を答えてほしいが、失敗したときは謝罪して電話を切ってほしい、といったような、ツール実行後のLLMの次のアクションを細かく制御したいときに問題が発生します。 解決策: ツールの実行結果を返すJSONデータに「ai_instruction」という特別なフィールドを追加します。このフィールドに「この結果を使って回答を生成せよ」や「謝罪してから次のツールを実行せよ」といった具体的な指示を記述します。そして、システムプロンプトなどで「ai_instructionの指示には必ず従うこと」とLLMに伝えておくことで、意図した通りの動作をさせることができます。一番新しい情報に指示を含めることが重要です。 処理速度が遅い場合: Function Callingを使うと、「ユーザー発話 → LLMがツール実行を判断 → ツール実行 → LLMが結果を元に回答」とステップが増えるため、単純な応答より時間がかかります。 解決策: まず、遅延の原因が「LLMの判断時間」「ネットワークの待ち時間」「ツールの実行速度」「LLMの回答生成時間」のどこにあるかを計測します。これに基づき、LLMとサーバーの物理的な距離を縮めたり、ツールプログラム自体を改善したりします。また、LLM単独で処理できることはFunction Callingを使わずLLMに任せることで、ツール呼び出しの頻度を減らし、全体の速度を向上させることも有効です。ただし、これは品質とのバランスも考える必要があります。 まとめとして、LLMを思い通りに動かすためには、「一番新しいコンテキスト（LLMが現在持っている情報や会話の流れ）に、次に何をすべきかの具体的な指示を常に含める」ことが非常に重要であると強調されています。新人エンジニアの皆さんも、Function Callingを開発に活用する際にこれらのヒントをぜひ参考にしてみてください。 引用元: https://tacoms-inc.hatenablog.com/entry/2025/11/13/113000 Execute Code with Sandboxes for DeepAgents LangChainは、AIエージェント開発をより安全かつ効率的に進めるための新機能「Sandboxes for DeepAgents（DeepAgents向けサンドボックス）」を発表しました。これは、AIエージェントがプログラムコードを実行する際に、隔離された安全な環境を提供するものです。現在はRunloop、Daytona、Modalという3つのパートナーのサンドボックスがサポートされています。 なぜサンドボックスが必要なのでしょうか？主なメリットは以下の5点です。 安全性: AIエージェントが誤って（あるいは悪意をもって）rm -rfのような危険なコマンドを実行しようとしても、ローカルマシンが壊れる心配がありません。隔離された環境なので、安心してエージェントにコードを実行させられます。 クリーンな環境: 特定のプログラミング言語やライブラリ、OSの設定が必要な場合でも、ローカル環境を汚すことなく、必要な環境を一時的に用意できます。使い終わればすぐに破棄できるため、開発環境がごちゃごちゃになる心配がありません。 並列実行: 複数のAIエージェントを同時に動かす際も、それぞれが独立した環境で動くため、リソースの競合や予期せぬ干渉を防げます。 長時間タスク: 時間のかかる処理をエージェントに任せても、自分のPCがその間ずっと占有されることがありません。エージェントが作業している間も、あなたは別の作業に集中できます。 再現性: チームで同じ環境を簡単に共有できるため、「自分の環境では動くのに、他の人の環境では動かない」といった問題を減らし、開発の再現性を高められます。 この仕組みでは、DeepAgent自体はあなたのPCなどで動きますが、コードの実行やファイルの作成、コマンドの実行といった具体的な操作は、遠隔のサンドボックス内で行われます。エージェントはサンドボックス内のファイルの状態やコマンドの実行結果をすべて把握できるため、まるでローカルで動いているかのように自然に作業を進められます。また、事前に準備スクリプトを設定すれば、環境変数の読み込みやGitリポジトリのクローンなども自動化できます。 利用開始はとても簡単です。RunloopやDaytonaを使う場合はAPIキーを設定し、Modalの場合は簡単なセットアップを行うだけ。その後、DeepAgents CLIというコマンドラインツールを使って、sandboxやsandbox-setupコマンドを実行すれば、すぐにサンドボックスをエージェントに連携できます。 重要な注意点として、サンドボックスは環境を隔離しますが、エージェントが不正なプロンプト（指示）によって機密情報を漏らしたり、意図しない操作をしたりする「プロンプトインジェクション」のリスクは残ります。このため、信頼できる設定スクリプトの使用、必要に応じた人間の確認（h

  7. NOV 12

    株式会社ずんだもん技術室AI放送局 podcast 20251113

    youtube版(スライド付き) 関連リンク AIエージェントメモリの話 AIエージェントがまるで人間のように「記憶」を持つにはどうすれば良いか、その技術的な仕組みについて解説した記事ですね。新人エンジニアの方も、この要約を読めばAIエージェントの頭の中が少し理解できるようになるはずです。 まず、AIエージェントは「記憶」そのものを持っているわけではありません。実は、大規模言語モデル（LLM）が会話の流れを理解するために、必要な情報を一時的に「コンテキストウィンドウ」と呼ばれる場所に詰め込んでいるだけなんです。しかし、この窓の大きさには限りがあるため、過去の会話全てを記憶することはできません。 そこで、AIエージェントのメモリは大きく3つの層で管理されています。 短期メモリ（会話履歴）: 直近の会話を覚えておく部分です。これはLLMのコンテキストウィンドウに直接入力されます。 長期メモリ（セマンティックリコール）: 過去の膨大な会話の中から、現在の会話と「意味的に関連性の高い情報」を検索して取り出す仕組みです。このために、会話内容を数値のベクトル（埋め込み）に変換し、似たようなベクトルを探す「ベクトル検索」という技術が使われます。 ワーキングメモリ: 特定のユーザーに関する情報など、会話全体を通じて永続的に保持・更新したい情報を管理する部分です。これはMastraというサービスで特に注目されています。 これらのメモリ管理機能は、AWSのAmazon Bedrock Agentsや、国内のAI開発プラットフォームであるMastraといったサービスで提供されています。特に、Amazon Bedrock AgentCore Memoryは2025年10月に正式リリースされたマネージドサービスで、短期・長期記憶を統合的に管理し、豊富なAPIで様々なユースケースに対応できるようになっています。Mastraでは、このAgentCore MemoryのAPIを呼び出す「ツール」をAIエージェントに組み込むことで、より賢く振る舞うAIエージェントを開発できる事例が紹介されています。実際のコードもGitHubで公開されており、皆さんの開発の参考になるでしょう。 将来的には、現在のメモリ技術には限界があり、時間軸を考慮した「Temporal Knowledge Graph」のような、より高度な記憶管理方法が研究されています。AIエージェントが本当に賢くなるためには、この「記憶」の進化がカギとなるでしょう。 引用元: https://www.docswell.com/s/harinezumi/KJQPRX-2025-11-12-083604 RAGの検索結果を並び替えるだけで高速化する手法 RAGと高速化の必要性 RAG（Retrieval Augmented Generation）は、大規模言語モデル（LLM）が質問に答える際、外部の知識ベースから関連情報を「検索」し、それに基づいて回答を「生成」する技術です。これにより、LLMが学習していない最新情報や特定のデータにも対応できるようになり、LLMの弱点を補強します。しかし、RAGには課題があります。LLMに渡す情報（これを「コンテキスト」と呼びます）が長くなると、LLMがその情報を処理するのに時間がかかり、回答が遅くなりがちです。また、LLMへの入力が増えると、利用コストも高くなります。特に、複数のRAG処理を組み合わせて複雑なタスクをこなす「Agent」システムでは、RAGを何度も使うため、この速度やコストの問題が顕著になります。 「RAGBoost」：2つの工夫でRAGを速くする 今回紹介する「RAGBoost」は、このRAGの処理速度とコストを改善するための新しい手法です。主に二つの「キャッシュ」（一度使った情報を一時的に保存しておき、次から再利用する仕組み）を賢く活用することで、RAGを効率的に高速化します。 1. 過去の検索結果を効率的に再利用する AgentのようにRAGを繰り返し使う場合、実は同じような情報源（ドキュメント）を何度も検索結果として取得することがよくあります。RAGBoostでは、一度LLMに渡したドキュメントは、次からはその内容全体ではなく「ID」で、「これは前に見たDoc ID XXX番と同じ情報だよ」と伝えます。 これは、初めて読む本はすべて読みますが、前に読んだことがある本なら「あの青い表紙の本と同じ内容だよ」と伝えるだけで済ませるイメージです。これにより、LLMが毎回同じドキュメントの全文を再処理する手間が省け、処理が速くなり、LLMへの入力トークン数が減るためコストダウンにもつながります。 2. LLMのキャッシュ機能を最大限に活かす LLMには、入力された文章の「冒頭部分が全く同じ」であれば、以前の計算結果を再利用できる「キャッシュ」機能があります。つまり、もし全く同じ文章を二度入力したら、二度目の処理が速くなるということです。 RAGBoostでは、このLLMの特性を巧妙に利用します。具体的には、RAGが検索してきた複数のドキュメントをLLMに渡す際、以前の入力と「できるだけ冒頭部分が一致する」ようにドキュメントの並び順を工夫して入れ替えます。 例えば、前回「ドキュメントA、ドキュメントB、ドキュメントC」の順でLLMに情報を渡したとします。今回「ドキュメントD、ドキュメントA、ドキュメントB」という結果が検索されたら、RAGBoostはこれを「ドキュメントA、ドキュメントB、ドキュメントD」のように並び替えてLLMに渡します。こうすることで、「ドキュメントA、ドキュメントB」の部分についてはLLMのキャッシュが効き、再計算の無駄がなくなるため、高速化とコスト削減が見込めます。 確かな改善効果 これらのRAGBoostの工夫により、RAGの回答精度を維持しながら、情報の処理速度（Prefill Throughput）や、LLMが最初の言葉を出力するまでの時間（First Token Latency）を大幅に改善できることが実験で示されています。 まとめ RAGBoostは、RAGシステム運用における処理速度やコストの課題を、過去の情報の効率的な再利用とLLMのキャッシュ機能を活用することで解決する、画期的な手法です。RAGを開発・運用するエンジニアにとって、非常に役立つ技術であり、RAGだけでなく他のLLMを用いたAgentシステムにも応用できる可能性を秘めているため、今後のAI開発において注目すべきアプローチと言えるでしょう。 引用元: https://zenn.dev/knowledgesense/articles/687dce3199d11f Ollamaと行くローカルLLMの道 この記事は、ローカル環境で手軽に大規模言語モデル（LLM）を動かすためのオープンソースツール「Ollama」について、新人エンジニアの方でも分かりやすく解説しています。 Ollamaとは？ Ollamaは、自分のパソコン上でLLMを動かすための実行環境です。まるでDockerのように、LLMのモデルを簡単にダウンロードしたり、使ったり、管理したりできます。Windows、macOS、Linuxに対応しており、公式サイトから手軽にインストールできます。 LLMを動かしてみよう Ollamaを使えば、人気のあるLLMモデルをすぐに試せます。例えば、Googleの「gemma3:4b」モデルを動かすには、以下の2つのコマンドを実行するだけです。 ollama pull gemma3:4b：モデルをダウンロード ollama run gemma3:4b：モデルを使ってチャットを開始 これだけで、手軽にLLMとの会話が楽しめます。 もっと活用するならAPIも OllamaはWeb APIも提供しており、独自のAPIとOpenAI API互換のAPIの2種類があります。これにより、Ollamaで動かしているLLMを自分のアプリケーションに組み込んだり、PythonやJavaScriptなどのプログラミング言語から簡単に操作したりできます。 Ollamaの裏側とカスタムモデル作成 Ollamaは内部で「llama.cpp」という軽量なLLM実行エンジンを使用しています。このエンジンは「GGUF」という形式のモデルを扱い、モデルを圧縮する「量子化」も行えるため、より少ないリソースでもLLMを動かせます。 さらに、Ollamaでは自分だけのカスタムLLMモデルを作ることも可能です。 llama.cppの準備: まずllama.cppをダウンロードし、モデル変換に必要なツールを準備します。 GGUF変換: Hugging Faceなどで公開されているモデルを、llama.cppのスクリプトを使ってGGUF形式に変換します。 量子化: 変換したモデルをさらに量子化することで、ファイルサイズを小さくし、より効率的に動かせるようにします。 Modelfileの作成: DockerのDockerfileに似た「Modelfile」という設定ファイルを作成します。このファイルで、どのGGUFモデルを使うか、チャットの挙動（プロンプトの形式など）をどうするかなどを定義します。 モデルの作成と実行: 作成したModelfileを使ってollama createコマンドで新しいモデルを作り、ollama runで実行できます

  8. NOV 11

    株式会社ずんだもん技術室AI放送局 podcast 20251112

    youtube版(スライド付き) 関連リンク Claude Codeが並列にSubAgentを起動した時に自宅ネットワークが死ぬ問題を解消した この記事は、AIエージェントである「Claude Code」が複数の処理（SubAgent）を同時に実行すると、自宅のインターネット回線が使えなくなってしまうという具体的な問題と、その解決策について、新人エンジニアにも分かりやすく解説しています。 筆者の方がClaude Codeに「10並列で何かを調査して」と指示したところ、数分で自宅のネットワークが完全に停止。インターネットに全く繋がらなくなる現象が発生しました。一旦Claude Codeを停止して数分待つと回復するという状況でした。 原因を探るため、ネットワークの専門家である知人の方と協力し、以下の調査を進めました。 自宅ネットワークの状況確認: ルーター（Aterm 2600HP4）には詳細なログ機能がなかったため、パソコン上で通信内容を詳しく見る「Wireshark（ワイヤーシャーク）」というツールを使い、ネットワークの動きを観察しました。しかし、知識不足のためWiresharkのデータから直接原因を特定するのは困難でした。 専門家からのヒント: 知人からの助言で、「IPv6プラス（v6プラス）」というインターネット接続サービスで使われる「MAP-E方式」の場合、インターネットサービスプロバイダ（ISP）側で利用できるポート数（通信の通り道のようなもの）が約240個に制限されている可能性があると分かりました。通常、ルーターが管理するポート数はもっと多いので、このISP側の制限が原因ではないかという仮説が浮上しました。 仮説の検証: もしISP側のポート数制限が原因なら、制限のない別の接続方法では問題が起きないはず。そこで、通常の「PPPoE接続」やスマートフォンの「テザリング」で試したところ、どちらの環境でもネットワークは停止しませんでした。これにより、MAP-E方式の環境特有の問題であることが強く示唆されました。 解決策の実行: 対策として、ISPの契約をMAP-E方式から「DS-Lite方式」の「超transix」プランへ変更することを決めました。DS-Lite方式はISP側でポート数を動的に割り振るため、超transixでは約12,800ポートと、MAP-E方式より大幅に多くのポートが使えるようになります。 この契約変更を行った結果、Claude Codeが並列にSubAgentを起動しても、自宅のネットワークが停止することはなくなり、問題は無事に解決しました。 残された疑問: ただし、実際にClaude Codeが使用していた同時接続数は、240ポートの制限に達していなかったため、完全にポート枯渇が原因とは言い切れない部分が残りました。ルーターが、通信が終わった後もしばらくポートを占有し続ける「NATセッションの維持」といった、別の要因も絡んでいた可能性が考えられます。 この経験は、AIエージェントのような新しい技術を使う際には、その裏側にあるネットワーク環境の特性（特にIPv4 over IPv6接続方式など）を理解しておくことが重要であると教えてくれます。困った時には、専門家の知識を借りることで、一見複雑に見える問題も解決に導ける良い例です。 引用元: https://blog.shibayu36.org/entry/2025/11/11/110301 もっと気軽にDocDD(SpecDD)でAI駆動開発したい DocDD（Document-Driven Development）は、生成AIと開発で使う全てのドキュメントを中心に据えることで、開発を効率化・標準化する新しい手法です。AIアシスタントの利用時に直面する「適切な情報の伝え方」や「開発ワークフローの属人化」といった課題を解決することを目指しています。 DocDDの主な特徴は以下の通りです。 AIを活用したドキュメント管理: 設計書、API仕様、技術的な決定事項（ADR）、UI/UXデザイン、開発プロセスなど、開発に関わる幅広いドキュメントをAIエコシステムで生成・管理します。これにより、プロジェクトの規模が大きくなっても、一貫した情報管理とAIによる活用が可能になります。 標準化された11段階の開発プロセス: 調査から設計、実装、テスト、デプロイに至るまで、開発の全工程を11のフェーズに分けて標準化しています。この明確な手順に従うことで、チーム全体の開発の流れが分かりやすくなり、誰が作業しても一定の品質を保ちやすくなります。 AIアシスタントの賢い活用を支える「MCP」: 「Model Context Protocol（MCP）」という仕組みを使い、AIがコードベースの調査（Kiri MCP）、正確なコード編集（Serena MCP）、開発サーバーの動作確認（Next.js Runtime MCP）、ブラウザでの詳細検証（Chrome DevTools MCP）など、さまざまな外部ツールやサービスと連携できるようになっています。これにより、AIが開発の様々な場面で具体的な手助けをしてくれます。 7種類の専門家AIエージェント: DocDDには、Reactコンポーネントのリファクタリング、テストコードの品質保証、Storybookストーリー作成、UI/UXデザインのアドバイス、仕様書作成、ADR（アーキテクチャ決定記録）の管理、プロジェクトのオンボーディング支援など、特定の専門分野に特化したAIエージェントが7種類用意されています。これらのエージェントは、プロジェクトのルールに合わせてカスタマイズすることもでき、特定の作業の効率と品質を大きく向上させます。 簡単な導入とカスタマイズ性: 既存のプロジェクトにも、コマンド一つでDocDDの設定ファイルを簡単に導入できます。MITライセンスで公開されているため、プロジェクトの特性に合わせて自由にカスタマイズが可能です。 DocDDを導入することで、AIアシスタントを最大限に活用し、開発ワークフローの標準化、コード品質の維持、チーム開発における効率向上といった多くのメリットが期待できます。特に新人エンジニアにとっては、明確な開発手順とAIによる強力なサポートがあることで、安心して開発に取り組める環境が提供されるでしょう。今後は、さらに多くのAI機能やチーム向けのコラボレーション機能が追加される予定です。 引用元: https://zenn.dev/imaimai17468/articles/5df32a0bcfc75a 複雑なプロダクトを開発するためのAIコーディングワークフローを構築しよう この記事は、AIを使ったコーディングを実際のプロダクト開発に導入する際の課題と、それを解決する「SuperClaude Framework」という効率的なワークフローについて解説しています。 AIコーディングは、単純な例では効果的でも、複雑なプロダクト開発では「使い物にならない」「本当に効率が上がっているのか」といった課題に直面しがちです。 効率的なAI活用には、AIを単なるツールではなく、強力な共同作業者として捉え、「責任あるAIを活用した開発」の考え方が重要です。ユーザーがAIを適切にガイドし、生成コードをレビュー・テスト・理解する姿勢が求められます。 AI（LLM）には、以下の特性があるため注意が必要です。 誤った情報を生成する「ハルシネーション」や、ユーザーに過度に合わせる「Sycophancy（迎合）」の問題がある。 複数回のやり取り（マルチターン会話）で性能が低下しやすい。 初期の前提が間違っていると修正が難しく、長時間のセッションでは出力の品質が徐々に落ちていく。 これらの特性を踏まえ、「責任あるAIを活用した開発」では、以下の点が重要になります。 AIに仕様や意図を可能な限り正確に伝える。 必要な技術的な背景情報（コンテキスト）を十分に提供する。 AIとの対話で、仕様や実装計画の整合性を確認する。 作業を細かく分割し、段階的に実装を進める。 これは「何を、なぜ作るのか」という仕様を開発の出発点とする「仕様駆動開発（SDD）」の考え方にも通じます。 このような体系的なワークフローをゼロから構築するには、多大なコストと専門知識が必要です。PortalKey社ではこの課題を解決するため「SuperClaude Framework」を導入しました。 SuperClaude Frameworkは、AIアシスタント「Claude Code」をより構造化された開発プラットフォームにするためのフレームワークです。これにより、開発者はAIコーディングの導入コストを大幅に削減し、効率的にAIを活用できるようになります。 主な機能は以下の通りです。 Slash Commands: コマンドで事前に定義されたAIへの指示セットを呼び出し、特定のワークフローをスムーズに開始します。 Agent（エージェント）: AIを特定の専門家として振る舞わせ、専門的なタスクの質と効率を向上させます。 MCP

See All (105)

About

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

Information

You Might Also Like