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

株式会社ずんだもん技術室AI放送局
  • 0,0 (0)
  • TECHNOLOGIES
  • TOUS LES JOURS

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

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

    -2 J

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

    youtube版(スライド付き) 関連リンク GitHub Copilot カスタムエージェントのための agents.md 作成ベストプラクティス GitHub Copilotの新しい「カスタムエージェント」機能をご存じでしょうか？これは、AIアシスタントに特定の役割や専門知識を与え、開発を効率化するものです。本記事は、このカスタムエージェントの設定ファイル「agents.md」の効果的な作り方を、新人エンジニアにも分かりやすく解説します。GitHubが2,500以上のリポジトリを分析して得た知見が基になっています。 agents.mdファイルは、リポジトリの.github/agents/に配置し、エージェントの役割、使用ツール（read, edit, shellなど）、プロジェクト構造、コードスタイルなどを定義します。これにより、バックエンド専門やフロントエンド専門といった、特化したエージェントチームを構築できます。 効果的なagents.mdには、以下の6つの要素が重要です。 コマンド: エージェントが実行する具体的なコマンドを明確に書きます。 テスト: 使用するテストフレームワークやテストの実行方法を具体的に指定します。 プロジェクト構造: ディレクトリ構成とその役割を記述し、エージェントがファイルを理解しやすくします。 コードスタイル: 推奨されるコードの書き方と避けるべき書き方を、具体的な例で示します。 Gitワークフロー: ブランチ命名規則やコミットメッセージのフォーマットなど、開発プロセスを定義します。 境界線: エージェントが「必ずやること」「確認が必要なこと」「絶対にやってはいけないこと」を明確にし、意図しない挙動を防ぎます。 曖昧な指示や複雑すぎる設計は、エージェントのパフォーマンスを低下させます。最初は完璧を目指さず、「最小限の設定から始め、問題があればルールを追加していく」という段階的なアプローチが推奨されます。 カスタムエージェントの大きな利点は、複数の開発タスク（Issue）に適切なエージェントをアサインし、並行して効率的に作業を進められることです。エージェントが正しく作業するためには、Issueに必要な情報（背景、要件、受け入れ条件など）がしっかり記載されていることが不可欠です。Issue作成自体もエージェントに任せることで、必要な情報が漏れなくそろい、開発の精度と効率がさらに向上するでしょう。 AIオーケストレーションを上手に活用し、皆さんの開発ライフをより豊かなものにしてください。 引用元: https://zenn.dev/studypocket/articles/github-copilot-agents-md-best-practices Programmatic Tool Calling(PTC)の何が新しいのか？ Anthropicが、対話型AI「Claude」の新しいAPI機能として「Programmatic Tool Calling」（PTC）を公開しました。これは、Claudeが外部のツールを使う方法を大きく進化させる技術です。新人エンジニアの皆さんも、これからのAIエージェント開発で役立つポイントなので、ぜひ知っておきましょう。 これまでのTool Use（ツール利用）では、Claudeがツールを一つ使うたびに「次はこれをやろう」と判断し、その結果を会話の履歴（これを「コンテキスト」と呼びます）に全て記録していました。ツールをたくさん使う複雑なタスクでは、このコンテキストがどんどん長くなり、「コンテキスト肥大化」という問題が起きていました。コンテキストが長くなると、情報処理のコストが増えるだけでなく、Claudeが重要な情報を見落としたり、判断を誤ったりする「context rot（コンテキスト腐敗）」と呼ばれる精度低下の問題も発生しやすかったのです。 PTCでは、この課題を根本的に解決します。Claudeは、複数のツールを呼び出す一連の処理をまとめたPythonコードを一度に生成します。このコードは、Anthropicが用意した特別な実行環境（「サンドボックス」と呼びます）の中で動きます。重要なのは、ツールが実行されたときの中間的なデータ（例えば、大量のデータ分析結果など）は、このサンドボックスの中にだけ保持され、Claudeのコンテキストには直接戻されない点です。Claudeが受け取るのは、サンドボックスでの処理が終わった後の「最終的な結果」だけになるため、コンテキストが肥大化するのを防げます。 実際に検証した結果、従来のTool Use方式と比較して、PTCを使うことで、Claudeに与える入力情報量（トークン）を約74%も削減できました。さらに、全体の処理時間も約24%短縮される効果が確認されています。これにより、より長く、より複雑なタスクでも、Claudeが効率的かつ正確にツールを使いこなせるようになります。 このPTCは、直接APIを使ってAIエージェントを開発するエンジニアにとっては、コンテキスト管理という核心的な問題を解決するための強力な技術となります。皆さんが将来、より賢く、より効率的に動くAIエージェントを開発する上で、このPTCのような技術は不可欠な要素となるでしょう。 引用元: https://blog.lai.so/programmatic-tool-calling/ vLLM+Structured Outputを使ったテキストのラベリング高速化 Wantedly Engineer Blog 本記事は、自然な文章で書かれた大量のテキストデータに、AI（大規模言語モデル、LLM）を使って効率的に「タグ付け（ラベリング）」を行う方法と、その処理を高速化する技術について解説しています。 私たちの周りにはたくさんのテキストデータがありますが、そのままでは扱いにくいことが多いです。そこで、文章の内容を意味ごとに整理し、適切なラベルを付ける「テキストラベリング」が重要になります。しかし、この作業は人間が手作業で行うと非常に大変ですし、自動化しようにも言葉の揺れなどで難しい側面がありました。 最近ではChatGPTのようなLLMが登場したおかげで、比較的簡単にテキストラベリングができるようになりました。LLMを使うと、どのような基準でラベルを付けるかを「プロンプト（指示文）」で伝えるだけで、柔軟にラベリング作業をコントロールできます。 さらに、自分のコンピュータ環境でLLMを動かす「ローカルLLM」を利用すれば、機密データを外部に出すことなくAIを活用できたり、APIの利用回数制限を気にせずに大量のデータを処理できたりするメリットがあります。 しかし、たくさんのテキストを一度にラベリングしようとすると、処理に時間がかかってしまうのが課題です。そこで、この記事では「vLLM」というライブラリを使って、ローカルLLMが答えを出す処理（推論）を大幅に速める方法を紹介しています。 また、ラベル付けでは、単に「AかBか」だけでなく、「有害かどうか」「もし有害なら、どんな種類の有害性か」といった、より複雑で「構造化されたラベル」が必要になることがあります。このニーズに応えるのが「Structured Output（構造化出力）」という機能です。これは、outlinesやvLLMといったライブラリを使うことで実現でき、事前に定義した形式（例えば、Pydanticというライブラリで作成するデータ型）に合わせてLLMが出力してくれるため、結果がとてもきれいに整理されます。 実際に実験として、日本語の有害テキストをラベリングするタスクで、vLLMとStructured Outputの機能を組み合わせて使用しました。その結果、従来のStructured Outputのみで推論するよりも、約6.5倍も高速にラベリングできることが分かりました。 まとめると、クラウドのLLMサービスが使えない状況でも、ローカルLLMに「vLLM」を導入し、「Structured Output」を組み合わせることで、複雑な構造を持つラベルを非常に速く生成できる、という具体的な技術応用事例です。新人エンジニアの皆さんにとって、LLMを実際のサービスに組み込む際のパフォーマンス向上や、精度を高めるためのヒントになること間違いなしです。 引用元: https://www.wantedly.com/companies/wantedly/post_articles/1021372 生成AIが発達してくる未来で俺が危惧してること「ドラレコの映像、証拠にならなくなるのでは…？」 生成AIの進化で、ドラレコ映像が改ざんされ事故の証拠にならなくなるのでは、という懸念が議論されています。過去の映像改ざん事例やデジタルデータの信憑性の問題が指摘される一方で、複数のカメラでの検証、時刻認証技術、改ざん防止機能付きドラレコ、GPSデータ記録など、信頼性を保つための技術や対策も挙がっています。AIが進化する中で、デジタルデータの証拠能力をどう担保していくか、今後の社会で考えるべき大切な課題です。 引用元: https://toge

  2. -3 J

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

    youtube版(スライド付き) 関連リンク 「Goで作る自作コーディングエージェント nebula 開発入門」が良かった この記事では、著者が「Goで作る自作コーディングエージェント nebula 開発入門」という書籍を通して、Go言語でAIコーディングエージェント「nebula」を実際に開発した体験談が語られています。著者はこの実践的な学習が非常に有益で、深い学びがあったと評価しています。 新人エンジニアの皆さんにとって、「AIエージェント」という言葉はまだ聞き慣れないかもしれません。これは簡単に言うと、まるで人間のように目標を設定し、外部の情報を使ったり判断したりしながら、自律的にタスクをこなすAIプログラムのことです。特に「コーディングエージェント」は、指示に基づいてコードを書いたり修正したりするAIですね。この本は、そんなAIエージェントの「仕組み」をGo言語で作りながら学べる、実践的な入門書です。 この実践で得られる主な学びは、AIエージェントの「賢さ」や「振る舞い」を司る重要な設計パターンです。例えば、 ツールコール: AIが外部のプログラムやAPI（例えば、ファイルを読み書きする機能やWeb検索機能など）を適切に呼び出し、利用する仕組み。これにより、AIは自身が持たない能力を拡張できます。 システムプロンプト設計: AIに対して「あなたはどのような役割で、どのように振る舞うべきか」を指示する、AIの「憲法」のようなもの。これをしっかり設計することで、AIは意図した通りに動きます。 メモリ機能設計: AIが過去の会話履歴や学習した情報を覚えておき、それを次の行動に活かす仕組み。人間が経験から学ぶように、AIも「記憶」を持つことでより高度な判断ができるようになります。 これらはコーディングエージェントだけでなく、あらゆるAIエージェント開発に応用できる基礎中の基礎であり、実際に手を動かして理解できたことが大きな収穫だったと著者は述べています。 著者はこの書籍の内容を参考に、自身のGitHubリポジトリ（https://github.com/shibayu36/nebula）で「nebula」を公開しています。単に写経するだけでなく、一部の設計を改善したり、セッション一覧表示やコードの差分表示といった実用的な機能を追加したりと、自分なりに工夫を凝らしている点も注目です。これにより、読者は単なる写経を超えた、より深い理解と応用力を養うヒントを得られるでしょう。 Go言語での開発経験があり、AIエージェントという新しい技術分野に挑戦してみたい新人エンジニアにとって、この書籍は最適な学習リソースとなるはずです。著者の経験から、全ての学習を終えるのにかかる時間は約10時間程度とのこと。短期間で実践的なAI開発の基礎を身につけ、今後のキャリアの選択肢を広げるきっかけにもなりそうです。AIの進化が著しい今、Go言語とAIエージェントの組み合わせは、皆さんのスキルアップに大いに役立つでしょう。 引用元: https://blog.shibayu36.org/entry/2025/11/25/170000 人工知能は拡散言語モデルの夢を見るか？ PredNext ブログ 2025年現在、「拡散言語モデル」という新しい技術が注目を集めています。これは、現在の大規模言語モデル（LLM）の主流である「自己回帰モデル型Transformer」が抱える性能上の課題を解決する可能性を秘めているためです。 現在のLLMは、文章を構成する単語（トークン）を一つずつ順番に予測して生成する「自己回帰モデル」という仕組みで動いています。この方式では、前の単語の生成が終わらないと次の単語の生成に進めないため、計算を並列に処理するのが難しいという特徴があります。さらに、モデルの規模が大きくなるにつれて、1トークンを生成するたびに非常に巨大なモデルデータ（例えば700億パラメータのモデルで70GB）を、メモリ（DRAM）からプロセッサ（GPUなど）へ何度も読み込む必要が生じます。このデータ転送の頻度と量が多すぎると、プロセッサがフル稼働できず、メモリとの間のデータ帯域が「ボトルネック」（処理速度の限界）となってしまうのです。 この非効率さを「B/F」（Bytes per FLOP：1回の浮動小数点演算に必要なデータ転送バイト数）という指標で表現します。プロセッサとメモリは物理的に離れた場所にあり、データのやり取りには時間がかかります。そのため、コンピュータは昔からB/F値が高い計算が苦手で、自己回帰モデル型Transformerは推論時にこのB/F値が高く、効率的な実行が難しいとされています。 そこで期待されるのが拡散言語モデルです。これは、画像生成で成功を収めている「拡散モデル」の考え方をLLMに応用したものです。拡散モデルは、元の画像にノイズを加えていき、そのノイズから元の画像を復元する過程を利用します。拡散言語モデルでは、文章の一部を[MASK]という特殊なトークンで隠し、その[MASK]部分に適切な単語を予測して埋めていく作業を繰り返すことで文章を生成します。 この方式の大きなメリットは、一度に複数の[MASK]トークンを並列で処理し、予測できる点にあります。これにより、モデルデータをメモリから読み込む回数を大幅に減らすことができ、B/F値を低く抑えられます。結果として、GPUなどのプロセッサをより効率的に活用できるようになる可能性があります。 しかし、拡散言語モデルの実用性についてはまだ議論の途中です。品質面では、同規模の自己回帰モデルと同程度の性能を発揮する研究報告もあります。一方、速度面では、完全な文章になるまで[MASK]の予測と除去を繰り返す必要があるため、繰り返し回数が増えると自己回帰モデル（特に「投機的デコーディング」のような高速化技術を導入したもの）よりも遅くなってしまう可能性も指摘されています。 まとめると、拡散言語モデルは自己回帰モデルの根本的な効率問題を解決する可能性を秘めていますが、品質と速度の両面で自己回帰モデルを「常に大きく上回る」とまでは言えないのが現状です。まだ多くの課題が残されており、今後の技術進化が期待される新しいトレンドと言えるでしょう。 引用元: https://prednext.com/blog/diffusion-language-model/ Continuous batching from first principles LLM（大規模言語モデル）を使ったAIチャットボットは、最初の応答まで少し時間がかかり、その後は1単語ずつ（トークンと呼びます）高速に生成されるのを見たことがあるかもしれません。これは、LLMがまずプロンプト全体を処理し（Prefill）、その後、前の生成結果を考慮しながら1トークンずつ予測していく（Decoding）ためです。この生成プロセスは計算コストが非常に高く、特に多くのユーザーが同時に利用するサービスでは、効率的な推論技術が求められます。その中でも特に重要なのが「Continuous Batching」という技術です。 この技術を理解するために、基礎から順に見ていきましょう。 1. Attentionメカニズム LLMが文章中の単語（トークン）間の関係性を理解する中心的な仕組みがAttentionです。Attention層だけが、異なるトークンが相互に影響し合う場所です。LLMはプロンプトの各トークンに対し、クエリ（Q）、キー（K）、バリュー（V）と呼ばれる情報を計算し、これらを組み合わせて次のトークンを予測します。このとき、「因果マスク（Causal Mask）」という仕組みによって、未来のトークンが過去のトークンの計算に影響を与えないように制御されています。最初のプロンプト全体を処理する段階をPrefillと呼びます。 2. KVキャッシュ LLMが一度Prefillで計算したKey（K）とValue（V）の情報を「KVキャッシュ」として保存しておくと、その後のDecoding段階でこれらの情報を再計算する必要がなくなります。これにより、Decodingの計算コストを大幅に削減し、次のトークン生成を高速化できます。まるで過去の計算結果をメモしておいて使い回すようなイメージです。 3. Chunked Prefill（チャンクプリフィル） プロンプトが非常に長い場合、GPUメモリに一度に収まらないことがあります。Chunked Prefillは、KVキャッシュを使いながら長いプロンプトを小さな塊（チャンク）に分割して順番に処理する技術です。これにより、メモリの制約をクリアしつつ、長いプロンプトも効率的に扱えるようになります。 4. Continuous Batching（コンティニュアスバッチング） 複数のユーザーからのリクエストを同時に処理して、LLMの「スループット」（単位

  3. -4 J

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

    youtube版(スライド付き) 関連リンク Introducing shopping research in ChatGPT ChatGPTに、商品の購入検討をサポートする「ショッピングリサーチ」という新機能が導入されました。この機能は、私たちが製品を選ぶ際にかかる時間と手間を大幅に削減し、より賢い選択を支援してくれます。 具体的には、「小さなアパートに最適な静音のコードレス掃除機を探して」「この3つの自転車から選ぶのを手伝って」のように、求めている商品をChatGPTに伝えるだけで、詳細な購入ガイドを作成してくれます。私たちはこれまで、何十ものサイトを比較検討したり、レビューを読み込んだりしていましたが、この機能がそれらの調査を代行してくれるのです。 ショッピングリサーチは、ユーザーの過去の会話履歴や「記憶」機能から得た情報を活用し、スマートな質問を通じてニーズを深く掘り下げます。例えば、予算や重視する機能など、具体的な条件を聞き出すことで、よりパーソナライズされた結果を提供します。電子機器、美容品、家庭用品など、特に詳細な情報が必要なカテゴリでその威力を発揮します。 利用方法はとても簡単です。商品に関する質問をすると、ChatGPTが自動的に「ショッピングリサーチ」の利用を提案してくれます。または、メニューから直接選択することも可能です。利用中は対話形式で、ChatGPTが提示する製品オプションに対して「興味なし」や「もっとこれに似たものを」といったフィードバックを返すことで、リアルタイムでリサーチ内容を調整し、希望に合った製品へと絞り込めます。数分後には、主要な製品、それぞれの違いや長所・短所、信頼できる小売店からの最新情報がまとまった、自分だけの購入ガイドが手に入ります。 この機能は、GPT-5 miniをベースに、ショッピングタスクに特化して強化学習で訓練されたモデルによって動いています。信頼性の高い情報源から情報を収集し、複数の情報源を統合して質の高い調査結果を生成します。また、透明性も重視されており、ユーザーのチャット内容が小売業者と共有されることはありません。結果は公開されている小売サイトの情報を元に生成され、低品質なサイトは避けられています。 ただし、まだ完璧ではないため、価格や在庫などの製品詳細には誤りが含まれる可能性もあります。最終的な購入の際には、必ず小売業者のサイトで最新情報を確認することが推奨されています。OpenAIは今後も、ユーザーの好みをより深く理解し、対応するカテゴリを増やし、製品の比較や発見をより直感的に行えるように、この機能を進化させていくとしています。この新しい機能は、AIアシスタントが単なる情報提供だけでなく、より具体的なタスクをこなす「AIエージェント」へと進化していることを示す良い例と言えるでしょう。 引用元: https://openai.com/index/chatgpt-shopping-research Using skills with Deep Agents Anthropic社が提唱する「エージェントスキル」という新しい概念をLangChainのAIエージェントフレームワーク「deepagents-CLI」がサポートしたという発表がありました。これは、AIエージェントの性能を向上させ、開発・運用の効率を高める重要な一歩です。 エージェントスキルとは、簡単に言うと、特定のタスクをこなすためのファイル群（SKILL.mdという説明ファイルと、それに関連するドキュメントやスクリプトなど）をまとめたフォルダのことです。AIエージェントは必要に応じて、これらのスキルを動的に見つけて読み込み、利用できます。 近年、Claude CodeやManusのような汎用AIエージェントが普及していますが、意外にも、これらのエージェントが実際に使うツールはごく少数であることが分かっています。彼らが少ないツールで多様なタスクをこなせる秘密は、コンピュータ自体へのアクセス（Bashシェルやファイルシステム操作）を持っている点にあります。これにより、人間がパソコンでファイル操作やスクリプト実行をするように、エージェントも特別なツールなしに多くの作業を行えるのです。LangChainのdeepagentsも、この原則に基づいてファイルシステム操作とコード実行機能を備えています。 エージェントスキルは、この考え方をさらに発展させたものです。ツールをたくさん用意するのではなく、ファイルシステム上に多様なアクションを実行するためのスクリプトや指示を配置し、エージェントがそれを活用するというアプローチです。Anthropicが定義するスキルは、YAML形式のメタデータとMarkdown形式の指示を含むSKILL.mdファイルで構成されます。 スキルには主に2つの大きなメリットがあります。 トークン効率の向上：エージェントがスキルを使う際、最初はSKILL.mdの要約情報（YAMLフロントマター）だけを読み込みます。タスク遂行に必要になった場合のみ、ファイル全体を読み込むため、AIの処理に使う情報量（トークン）を削減できます。これにより、コンテキストウィンドウの肥大化を防ぎ、より複雑なタスクに対応しやすくなります。 エージェントの認知負荷軽減：エージェントは、多くの複雑なツールの中から適切なものを選ぶ代わりに、より基本的な（アトミックな）少数のツールを使ってファイルシステム上のスキルを呼び出します。これにより、ツール選択の混乱を減らし、エージェントがタスクに集中しやすくなります。 さらに、スキルは「継続的な学習」への道を開き、エージェントが新たなタスクに遭遇した際に新しいスキルを自律的に作成したり、エージェント間で簡単にスキルを共有したり、複数のスキルを組み合わせて使ったりすることも可能になります。 deepagents-CLIでは、このスキル機能を簡単に利用できます。公開されている豊富なスキルコレクション（Anthropic社やSkillsMPなど）を自分のエージェントにコピーするだけで、すぐに利用可能です。設定後、deepagents skills listコマンドで利用可能なスキルを確認できます。エージェントにスキルに関連するリクエストを出すと、自動的に該当するSKILL.mdを読み込み、スキルを実行してくれます。 引用元: https://blog.langchain.com/using-skills-with-deep-agents/ Google Antigravity IDEで焼き肉部位サイトを作ってみた - 開発フローと知っておくべき機能 Google Antigravity IDEは、Googleが提供する最新のAI統合開発環境です。この記事では、これを使って「焼き肉部位確認サイト」を開発した体験を紹介します。AIを活用した開発の面白さや、知っておくべきポイントを新人エンジニアの皆さん向けにまとめました。 「焼き肉の部位が視覚的にわかるWebサイトを作りたい」とプロンプトを入力すると、AIが「Implementation Plan（計画書）」を自動作成。これはレビュー可能で、コメントで修正指示（例：「日本語化」）を出せます。計画実行後、Webサイトと「Walkthrough（報告書）」が生成されます。 初期サイトの画像が期待と違ったため、「リアルな写真も」と報告書にコメント。すると、Antigravity搭載の画像生成AI「nano banana」がリアルな焼き肉写真を生成し、サイトに組み込み改善してくれました。このように、AIとの対話とレビューを通じて効率的に開発を進められます。 Antigravity IDEには、開発を助ける便利な機能があります。 会話モード: 複雑な作業には「Plan」、簡単な作業には「Fast」を使い分けます。 スクリーンショット/画面録画: ブラウザ画面をAIに取得させ、特定部分を指定して修正依頼が可能です（ブラウザ拡張機能必須）。 エージェントモード: Ctrl + Eで開くこのモードはAIとの対話がメイン。「Workspaces」で複数プロジェクト管理、「Playground」で現在の作業を汚さずにAIに質問できます。AIの計画や進捗も確認しやすいです。 エージェントの設定（特に重要！）: レビューポリシー: AIが勝手に作業を進めないよう「Request Review」に設定し、必ず確認が入るようにしましょう。 ターミナルコマンド実行: セキュリティのため「off」にし、許可するコマンドだけリストに追加して実行するのが推奨です。 ファイルアクセス: 情報漏洩リスクを避けるため、ワークスペース外のファイルへのアクセスは「off」にすることを強く推奨します。 Google Antigravity IDEは、nano bananaのような強力なAIが統合され、アイデアを楽しく効率的に形にできます。AIと共に開発を進める経験は、新人エンジニア

  4. -5 J

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

    youtube版(スライド付き) 関連リンク Google Antigravity のスタートガイド    Google Codelabs 皆さん、こんにちは！今回は、Googleが新たに発表した画期的なAI開発プラットフォーム「Google Antigravity」について、新人エンジニアの皆さんにも分かりやすくご紹介します。 Antigravityは、今までの開発環境（IDE）を「エージェントファースト」という新しい時代へと進化させるツールです。従来のAIがコードを自動補完するだけだったのに対し、AntigravityではAIがまるで一人前のエンジニアのように、開発の「計画」「コーディング」「ウェブサイトの調査」「テスト」といった複雑なタスクを、自律的にこなしてくれます。私たちはAIに細かい指示を出すというより、プロジェクト全体のゴールを伝え、AIエージェントにその達成を任せる、というイメージですね。 このプラットフォームの主な特徴は以下の通りです。 エージェントマネージャー（ミッションコントロール）: 複数のAIエージェントを同時に管理できる「管制室」のようなダッシュボードです。例えば、「認証機能をリファクタリングして」「依存関係を更新して」といった異なるタスクを複数のAIエージェントに並行して指示し、進捗を一覧で確認できます。まるでプロジェクトマネージャーのように、AIエージェントたちを指揮する感覚です。AIエージェントにどれくらいの自由度で作業させるか（ターミナルコマンドの実行や、作業内容のレビューを求める頻度など）も細かく設定できます。 エディタ: お馴染みのVS Codeをベースに作られており、コード編集のしやすさはそのままに、AIエージェントとの連携が強化されています。コードの一部をハイライトして「ここをもっと効率的にしてほしい」「このロジックにコメントを追加して」といった指示を直接AIに出せるのが便利です。 Antigravityブラウザ: AIエージェントが自らChromeブラウザを操作し、ウェブサイトにアクセスして情報収集をしたり、開発したウェブアプリケーションの動作検証を行ったりできます。人間がブラウザを操作するのと同じように、クリックやスクロール、入力などが可能です。 アーティファクト: AIエージェントが作業する過程で作成する「作業記録」のことです。例えば、タスクの計画書、コードの変更点（差分）、画面のスクリーンショット、テスト結果の動画などが自動で生成されます。これにより、AIが「何を」「どうやって」作業したのかが明確になり、その作業が正しかったのかを人間が簡単に確認・承認できるようになります。 具体的な活用例としては、以下のようなことができます。 Googleニュースのようなウェブサイトから最新情報を自動で抽出し、要約する。 PythonとFlaskを使ったウェブサイトを一から生成し、さらに機能を追加したり修正したりする。 ポモドーロタイマーのようなシンプルな生産性向上アプリを生成し、デザインや機能の改善をAIに依頼する。 既存のPythonコードに対して、AIが自動で単体テストコードを生成し、実行してその検証まで行う。 Antigravityは、AIが開発プロセスに深く関わる「エージェントファースト」という新しい働き方を提案しています。プログラミングの経験がまだ浅い新人エンジニアの皆さんでも、AIエージェントの力を借りて、複雑な開発タスクに挑戦したり、効率的に学習を進めたりできる素晴らしいツールです。ぜひ一度、この新しい開発体験を試してみてはいかがでしょうか。 引用元: https://codelabs.developers.google.com/getting-started-google-antigravity?hl=ja 仕様書駆動開発で一番いいAIモデル&エージェント検証 11/23版 この記事は、最新のAIモデル（GPT5.1、Gemini 3.0、Sonnet 4.5など）を使い、ソフトウェア開発の手法の一つである「仕様書駆動開発（SDD）」において、どのAIエージェントが最も効果的かを検証したものです。AIが仕様書を作成し、その仕様書に基づいてコードを実装するという2つの段階に分けて、各モデルの性能が比較されています。 検証は、個人開発中のゲーム（約4万行のコードベース）に「歯車システムが特定の条件で破壊される」という機能を追加するタスクを例に行われました。 評価対象となったAIエージェント: codex-cli (GPT-5.1) claude-code (Sonnet-4.5) Cursor + gemini-3.0-pro-preview 検証結果：仕様書作成の段階 当初、AIによる評価では、内容が包括的で読みやすい日本語だったClaude（Sonnet-4.5）の仕様書が最も良いと判断されました。しかし、実際にその仕様書をもとにコードを実装させたところ、Gemini 3.0が作成した仕様書から最も質の高い実装ができました。 この結果から、AIは文章量の多いものを良いと評価する傾向がありますが、必ずしもそれが実装のしやすさにつながるとは限らないという考察が述べられています。むしろ、詳細に記述しすぎず、ざっくりとした仕様書の方が、実装を担当するAIがコードの文脈を深く理解し、より柔軟で最適なコードを生成できる可能性が示唆されました。 検証結果：コード実装の段階 仕様書作成とは別に、純粋な「コード実装力」についても比較が行われました。同じ仕様書を使ってAIエージェントに実装させた結果、codex-cli (GPT-5.1-codex-max) が最も優れた実装を生成しました。 Gemini 3.0による実装は、不自然なコードや不要な記述が多く見られ、もし開発者が手直しをする場合、かなりの修正量が必要になると判断されました。これは、Gemini 3.0がソフトウェアエンジニアリングのベンチマーク（SWE-Bench）で他のモデルにやや劣るスコアであることとも一致しています。 結論 今回の検証では、仕様書作成の段階ではGemini 3.0が、そして実際のコード実装の段階ではcodex-cli (GPT5.1) が最も優れたパフォーマンスを発揮するという結論に至りました。 ただし、この検証は一つのプロジェクトにおける特定のテストケースでの結果であり、AIモデルは日々進化しているため、今後のアップデートによって最適な選択は変わる可能性があります。 引用元: https://zenn.dev/sakastudio/articles/a5ea1eee97ec37 Build and Run Secure, Data-Driven AI Agents この記事は、NVIDIAが提供する「AI-Q Research Assistant」と「Enterprise RAG Blueprints」というAIエージェントの構築方法について、AWS上でのセキュアかつ効率的なデプロイに焦点を当てて解説しています。新人エンジニアの皆さんにとって、AIエージェントがビジネスでどのように活用され、どのように構築できるのかを理解する良い機会になるでしょう。 生成AIの進化により、企業は自社のデータに基づいて、正確で信頼性の高いAIエージェントを求めています。NVIDIAのこれらの「ブループリント」（設計図のようなもの）は、大規模言語モデル（LLM）と検索拡張生成（RAG）技術を組み合わせることで、大量のドキュメントから必要な情報を理解し、要約したり分析レポートを作成したりするのを自動化します。 ソリューションの核となるのは、以下の2つです。 Enterprise RAG Blueprint: これは、企業内の文書（PDFやレポートなど）からテキスト、表、図などの情報を抽出し、ベクトルデータベースに保存します。ユーザーが質問すると、関連する情報をデータベースから検索し、LLMを使って文脈に沿った正確な回答を生成します。これにより、社内ナレッジベースからの迅速な情報検索が可能になります。 AI-Q Research Assistant: RAGの基盤の上に構築され、さらに高度な「エージェント」としての機能を提供します。ユーザーの複雑な調査プロンプトを分析し、社内データ（RAG）とリアルタイムのWeb検索（Tavily API）を使い分けて情報を収集します。そして、これらの情報を整理・統合し、詳細なレポートを自動生成します。これは、まるで専属のリサーチャーを雇うような体験です。 これらのAIエージェントは、Amazon Web Services (AWS) 上に安全かつスケーラブルにデプロイされます。主要なAWSサービスとして、コンテナ化されたAIアプリケーション（NVIDIA NIM microservices）を管理する「Amazon EKS」、企業データを保管する「Amazon S3」、ベクトルデータを効率的に検索する「Amazon OpenSearch Serverless」が利用されます。特に注目すべきは、「Karpenter」というツールで、AIに必要なGPUリソースを、必要な時に必要なだけ自動的に準備し、コストを最適化してくれます。 デプロイは、Terraformなどのツールを使った自動化

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

    20 NOV.

    私立ずんだもん女学園放送部 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の

  6. 19 NOV.

    株式会社ずんだもん技術室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が大きくなりすぎることがあり、人間

  7. 18 NOV.

    株式会社ずんだもん技術室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でどのように実装されて

  8. 17 NOV.

    株式会社ずんだもん技術室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消費のバランスを取っています。少ないリソースで学習を安定させるため、バッチサ

Tout afficher (109)

À propos

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

Informations

Vous aimeriez peut‑être aussi