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

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

By 株式会社ずんだもん技術室AI放送局Technology
Download on the App Store

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

  • 株式会社ずんだもん技術室AI放送局 podcast 20260416
    youtube版(スライド付き)
    関連リンク
    • AI エージェント kuro が入社しました
    • STORES 株式会社の技術推進本部において、2026年2月より「新入AI社員」として稼働を開始した自律型AIエージェント「kuro」の活動事例を紹介する記事です。LLM(大規模言語モデル)をベースにしたkuroは、SlackやGitHub上でエンジニアと肩を並べて業務をこなしています。

      1. 驚異的なアウトプット量

      入社から約2ヶ月間で、kuroが作成してマージされたプルリクエスト(PR)は約1500件、レビューしてマージされたものは約1200件にのぼります。1日に70件以上のPRを作成することもあり、人間には不可能なスピードで開発サイクルを回しています。

      2. エンジニアを支える具体的な実務内容

      kuroは単なる自動化スクリプトではなく、判断を伴う多様なタスクを自律的にこなします。

      • エラー調査と修正提案: Sentryなどで検知したエラーの根本原因を特定し、修正方針の提案からPR作成までを一貫して行います。
      • 問い合わせの初動対応: 顧客からの問い合わせ内容を分析し、バグの原因調査や修正実装、さらには「誰に確認すべきか」という担当者の特定までサポートします。
      • 自然言語によるデータ分析: SQLなどを直接書かなくても、自然言語で依頼するだけでクエリを発行し、結果をNotionへアップロードするなどの分析業務を代行します。
      • 高度なレビューと報連相: 複数のリポジトリを跨ぐ複雑な修正においても、関係者にメンションを送って判断を仰ぐなど、組織の期待値に沿った「適切なコミュニケーション」をとりながら業務を進めます。
      • 大量の定型作業: 数多くのリポジトリに点在するフラグ削除といった、人間が行うには負荷の高い「雑用」も一手に引き受けます。
      • 3. AIと共存する開発の未来

        AIエージェントを導入することは、強力な仲間を得る一方で、プロンプトインジェクションなどのセキュリティリスク管理や、適切な「教育」という手間も発生します。しかし、単純作業や初期調査をAIに任せることで、人間はより本質的でクリエイティブな課題解決に集中できるようになります。

        新人エンジニアにとっても、AIを「道具」として使う段階から「自律的な同僚」として共生する段階への進化を感じさせる、非常にワクワクする事例となっています。

        引用元: https://product.st.inc/entry/2026/04/14/114807

        • Inside VAKRA: Reasoning, Tool Use, and Failure Modes of Agents
        • IBM Researchが開発した「VAKRA」は、AIエージェントが実務環境でどれだけ正確に推論し、ツール(API)を使いこなせるかを測定するための新しいベンチマークです。従来のベンチマークは単一のスキルを個別にテストするものが多かったのに対し、VAKRAは「複数のAPI実行」と「文書検索(RAG)」を組み合わせた、より実践的で複雑なワークフローの完遂能力を評価します。

          VAKRAの概要と特徴

          VAKRAは、62のドメインにわたる8,000以上のローカルAPIと、それに関連する膨大なドキュメント群で構成される実行可能な評価環境を提供します。新人エンジニアが理解しておくべきポイントは、AIが単に「答える」だけでなく、「実際にプログラム(API)を動かして結果を確認しながら推論を進める」という点に主眼を置いていることです。

          具体的には、以下の4つの能力(Capability)を評価します:

          1. API連携(BIツール風): 複数のAPIを順番に呼び出し(1〜12ステップ)、データをフィルタリング・加工して答えを導く能力。
          2. 大量のツール選択: 数百件あるAPIの中から、目的に合った正しいAPIを正確に選び出す能力。
          3. マルチホップ推論: 複数の情報源をたどり、段階的に謎を解いていくような複雑な問いに答える能力。
          4. マルチソース推論とポリシー遵守: APIと文書(RAG)の両方を使い分けつつ、「特定の条件下ではこのツールを使わない」といった自然言語のルール(ポリシー)に従う能力。
          5. 評価の仕組み:ウォーターフォール型評価

            VAKRAの評価は非常に厳格です。「最終的な答えが合っているか」だけでなく、その結論に至るまでの「ツールの呼び出し順序」や「引数の正確さ」もチェックされます。まずルールを守っているかを確認し、次に実行ログを検証し、最後に回答の正誤を判断するという段階的なプロセス(ウォーターフォール型)で採点されます。

            分析から見えた現状の課題

            最新のAIモデル(GPT-OSS-120BやGeminiなど)を用いた分析の結果、以下の傾向が明らかになりました:

            • 推論の深さに比例して精度が低下: ステップ数(ホップ数)が増えるほど、AIは情報の取りこぼしや誤った推論をしやすくなります。
            • 制約(ポリシー)への対応が困難: 「この場合は検索のみ使う」といったルールが加わると、AIは混乱しやすく、実用化における大きな壁となっています。
            • ツール選択と引数のミス: 似たようなAPIが多い環境では選択を誤ったり、必要なパラメータを忘れたりする「うっかりミス」が依然として多い状況です。
            • 結論

              VAKRAは、AIエージェントが「表面的なツール利用」から「信頼できる実務代行」へと進化するために必要な課題を浮き彫りにしました。エンジニアにとって、AIエージェントを構築する際は単なる回答精度だけでなく、複雑な手順の構築能力や制約遵守の堅牢性をどう高めるかが今後の鍵となります。

              引用元: https://huggingface.co/blog/ibm-research/vakra-benchmark-analysis

              • Trusted access for the next era of cyber defense
              • OpenAIは、サイバーセキュリティの防御側(デフェンダー)を支援するための新しい取り組み「Trusted Access for Cyber (TAC)」プログラムの拡大と、サイバーセキュリティ特化型モデル「GPT-5.4-Cyber」を発表しました。このニュースは、これからのセキュリティエンジニアの働き方を大きく変える可能性を秘めています。

                1. サイバー防御特化型モデル「GPT-5.4-Cyber」の登場

                最も注目すべきは、最新モデルGPT-5.4をサイバーセキュリティの防御用途にファインチューニングした「GPT-5.4-Cyber」の導入です。

                通常、AIモデルには悪用を防ぐための「拒絶(ガードレール)」が設定されていますが、このモデルは「正当なセキュリティ業務」においてその制限を緩和しています。これにより、これまでAIが回答を拒んでいたようなバイナリの逆コンパイルや、マルウェアの解析、脆弱性の特定といった高度な防御ワークフローがスムーズに実行可能になります。

                2. 信頼に基づくアクセス制御(TACプログラム)

                OpenAIは「民主的なアクセス」「反復的なデプロイ」「エコシステムの回復力」の3原則を掲げています。

                高度な機能を持つGPT-5.4-Cyberは、誰にでも開放されるわけではありません。強力な本人確認(KYC)を通じた「信頼できる防御者」であることを証明した個人やチームに提供されます。これにより、AIが悪意ある攻撃者に利用されるリスクを抑えつつ、インフラや公共サービスを守るエンジニアが最新のAIツールを最大限に活用できる環境を整えています。

                3. エコシステム全体の強化

                OpenAIは単にモデルを提供するだけでなく、開発サイクルの中にセキュリティを組み込むことを推奨しています。

                • Codex Security: コードベースを自動監視し、脆弱性の修正案を提示するツールです。すでに3,000件以上の深刻な脆弱性の修正に貢献しています。
                • 継続的なリスク低減: 定期的な監査や静的なバグ修正ではなく、AIエージェントが開発ワークフローに統合されることで、コードを書いている最中にリアルタイムでセキュリティ上のフィードバックが得られる世界を目指しています。
                • 新人エンジニアへのメッセージ

                  これからのセキュリティエンジニアにとって、AIは「単なるチャットツール」ではなく、「解析や修正を共に行うパートナー」になります。GPT-5.4-Cyberのような特化型モデルを使いこなすには、AIの特性を理解しつつ、出力された結果の妥当性を判断する基礎的なセキュリティ知識がますます重要になります。

                  OpenAIは、攻撃者がAIを利用するスピードに対抗するためには、防御側のエンジニアがそれ以上のスピードでAIを活用する必要があると考えています。TACプログラムへの参加や本人確認を行うことで、皆さんもこの最先端の防御ツールを手に取ることができるようになります。AIと共に戦う「次世代のエンジニア」としての第一歩を、ここから踏み出してみてはいかがでしょうか。

                  引用元: https://openai.com/index/scaling-trusted-access-for-cyber-defense

                  • 大学院の試験で「AI使ってOK」だったので「楽勝やろ」と思って問題文をコピペして答えを聞いたのに「b」しか出力されない…→調べたら絶句する仕掛けが施されていた
                  • 大学院の試験でAI使用が許可された際、問題文に「プロンプトインジェクション」の罠が仕込まれていた事例が注目を集めています。Claudeにコピペすると「b」としか返さないよう不可視文字で指示が隠されており、単なるコピペでは解けない仕組みでした。これはAIを使いこなすリテラシーや、入力データの安全性を確認する重要性を問う内容といえます。新人の皆さんも、LLMへの入力に潜む罠には注意を払いましょう。

                    引用元: https://togetter.com/li/2686397

                    • お便り投稿フォーム
                    • (株式会社ずんだもんは架空の登場組織です)

                      0 min
                    • 株式会社ずんだもん技術室AI放送局 podcast 20260415
                      youtube版(スライド付き)
                      関連リンク
                      • Enterprises power agentic workflows in Cloudflare Agent Cloud with OpenAI
                      • CloudflareとOpenAIの強力な提携により、企業の業務自動化(エージェント・ワークフロー)が次世代のフェーズに突入しました。本記事の主要なトピックは、Cloudflareのプラットフォーム「Agent Cloud」において、OpenAIの最新モデル「GPT-5.4」を含むフロンティアモデルが直接利用可能になったことです。

                        【新人エンジニアが押さえておくべき3つのポイント】

                        1. AIエージェントによる「実業務」の自動化

                          これまでAIは「質問に答えるチャット」としての利用が主流でしたが、Agent Cloudでは「実際の仕事を行う」エージェントをデプロイできます。具体的には、顧客への自動応答、システムの更新、レポート生成などの複雑なタスクを、セキュアかつ本番環境で即座に動作させることが可能です。

                        2. エッジコンピューティングによる高速化

                          このサービスは、Cloudflareの「Workers AI」上で動作します。これは、世界中に分散されたサーバー(エッジ)でAIを動かす仕組みです。新人の方にとっての利点は、「知能とユーザーの物理的な距離を縮める」ことで、超低遅延(スピーディ)かつグローバルな規模で動作するAIアプリを、複雑なインフラ構築なしに実現できる点にあります。

                        3. 開発者向けツール「Codex」の統合

                          コード生成や開発支援に特化した「Codex harness」がCloudflareのサンドボックス環境(安全なテスト環境)で利用可能になりました。これにより、開発者はセキュアな環境でAIエージェントを構築・テストし、そのまま実環境へデプロイするワークフローをスムーズに進めることができます。

                          【背景と今後の展望】

                          CloudflareのCTOであるDane Knecht氏は、この提携が「AIネイティブな次世代スタック」を構築するための基盤になると述べています。すでにWalmartやAccentureといった世界的大企業がOpenAIの技術をビジネスの核に据えており、APIの処理量は毎分150億トークンを超える規模に達しています。

                          今回の統合は、AIエージェントが「実験的なツール」から、企業の生産性を支える「標準的なインフラ」へと進化したことを象徴するニュースです。エンジニアにとっては、インフラとAIが密接に統合されたことで、より高度なアプリケーションを素早く世界に届けるチャンスが広がっています。

                          引用元: https://openai.com/index/cloudflare-openai-agent-cloud

                          • Azure AI SearchのAgentic Retrievalを使ってAgentic RAG実現
                          • Microsoft AzureのAI Searchに追加された新機能「Agentic Retrieval(プレビュー)」を活用し、自律的な検索を行う「Agentic RAG」を実現する方法についての技術解説です。

                            Agentic Retrievalとは

                            従来のRAG(検索拡張生成)は、ユーザーの質問をそのまま検索に利用するシンプルなものが主流でした。これに対しAgentic Retrievalは、LLMがユーザーの意図を分析して「自律的に」必要なクエリを複数作成し、検索結果を集約して回答を生成します。これにより、一回の検索では解決できない複雑な質問に対しても、AIが必要な知識を自ら探しに行く挙動が可能になります。

                            制御の鍵となる2つのパラメータ

                            本機能を利用する際、エンジニアが調整すべき重要な設定が2つあります。

                            1. Output Mode(出力モード)
                              • ANSWER_SYNTHESIS: 取得した根拠を元に、LLMが自然な回答文を生成します。
                              • EXTRACTIVE_DATA: 根拠となるデータの断片(チャンク)のみを返します。自前で回答ロジックを組みたい場合に適しています。
                              • Reasoning Effort(思考の深さ)
                                • minimal: クエリ計画を行わず、直接的な検索のみを実行します。
                                • low: 質問を複数のサブクエリに分解して検索を実行します。
                                • medium: 目的の情報が得られるまで、より深く広範囲な探索を繰り返します。
                                • 実証実験の結果と考察

                                  記事では、IPAの公開ドキュメントをデータソースとし、設定ごとの挙動を比較しています。

                                  • Reasoning Effort = low: 3つのクエリが生成され、情報量の多い冗長な回答が返る傾向にありました。
                                  • Reasoning Effort = medium: 10個ものクエリが生成され、広範囲を検索した上で、要点を絞った非常に精度の高い回答が得られました。
                                  • トレードオフ: 思考を深くするほど回答精度は向上しますが、実行時間は50秒近くかかり、消費トークン数(コスト)も大幅に増加します。
                                  • エンジニアへのアドバイス

                                    これまでLangChainなどの外部ライブラリを組み合わせて複雑に実装していた「検索エージェント」の仕組みが、Azure AI Search側の設定だけで完結するようになった点が大きな進歩です。

                                    新人エンジニアの方は、まずはlow設定から始め、AIがどのように質問を分解(クエリ展開)しているかをログで観察することをおすすめします。アプリケーションの要件に応じて、コスト・速度・精度のバランスを見極めるのが、Agentic RAGを使いこなす第一歩となります。

                                    引用元: https://acro-engineer.hatenablog.com/entry/2026/04/14/120000

                                    • Claude Mythos Preview: Vertex AI で限定公開プレビュー版を提供開始
                                    • Google Cloudは、2026年4月13日、Anthropic社の最新かつ最高峰のモデルである「Claude Mythos Preview」を、Vertex AIの一部ユーザー向けに限定公開プレビュー版として提供開始しました。このリリースは「Project Glasswing」というプロジェクトの一環として行われており、AI業界でも注目度の高いニュースです。

                                      新人エンジニアの皆さんに分かりやすく解説すると、今回の発表の要点は以下の3点です。

                                      1. Anthropic社の最高性能モデルの登場

                                        Claude Mythosは、現在提供されているClaudeシリーズ(Opus 4.6やSonnet 4.6など)を凌駕する、Anthropic社で最も強力な汎用モデルとされています。これにより、これまで以上に複雑な論理推論や高度なタスク処理が可能になります。

                                      2. サイバーセキュリティへの重点的な取り組み

                                        このモデルの大きな特徴は、多様なユースケースで高いパフォーマンスを発揮するだけでなく、「サイバーセキュリティリスクの低減」に新たな焦点を当てている点です。AIの安全な利用が求められるエンタープライズ(企業)環境において、より安心して導入できる設計がなされています。

                                      3. Vertex AIによる強力なバックアップ

                                        Google Cloudの「Vertex AI」プラットフォーム上で提供されるため、エンジニアはエンタープライズグレードの管理機能を利用できます。AIアプリケーションやエージェントの構築、スケーリング、そして管理を効率的に行える環境が整っており、最新のモデルをすぐに実務レベルのインフラに組み込める点が大きなメリットです。

                                        現在は限定公開プレビューという段階であり、利用できる顧客は限られていますが、Google CloudとAnthropic社の強力なパートナーシップにより、最先端のAI技術がより身近で安全なものになろうとしています。

                                        新人エンジニアの方は、まず既に一般公開されている「Claude Opus 4.6」や「Claude Sonnet 4.6」などをVertex AIで触ってみることから始め、この「Mythos」がどのように進化していくのかを注視しておくと、AI技術のトレンドを掴みやすくなるでしょう。

                                        引用元: https://cloud.google.com/blog/ja/products/ai-machine-learning/claude-mythos-preview-on-vertex-ai

                                        • 猫成分に飢えていた親が「穴の空いたバケツ」のような元野良猫によってすべての愛を搾り取られていたマンガ
                                        • 元野良猫「ごんた」が家猫となり、飼い主の親御さんの愛を一身に受ける日常を描いた漫画です。先住猫に避けられ「猫成分」に飢えていた親御さんの前に現れたのは、誰にでも無限に甘える「穴の空いたバケツ」のような性格のごんたでした。際限なく愛を求め吸い尽くす猫と、全力で愛を注ぐ親御さんのコミカルで温かい交流は、業務に励むエンジニアの癒やしに最適です。新人の方もこの「無限の愛」のループにぜひ癒やされてください。

                                          引用元: https://togetter.com/li/2685909

                                          • お便り投稿フォーム
                                          • (株式会社ずんだもんは架空の登場組織です)

                                            0 min
                                          • 株式会社ずんだもん技術室AI放送局 podcast 20260414
                                            youtube版(スライド付き)
                                            関連リンク
                                            • 分析エージェントの問題点と、セマンティックレイヤーという打ち手──AIにSQLを書かせない設計
                                            • 「自然言語でデータ分析ができるAIエージェント」は非常に魅力的ですが、実務に導入すると「回答の数字が毎回違う」「定義が曖昧」といった信頼性の問題に直面します。本記事では、AIに直接SQLを書かせる従来のアプローチ(Text-to-SQL)の限界を指摘し、その解決策として「セマンティックレイヤー」を組み合わせた堅牢な設計手法を提案しています。

                                              1. AIによるSQL生成(Text-to-SQL)が抱える4つの課題

                                              新人エンジニアがまず知っておくべきは、LLM(大規模言語モデル)に直接DBを操作させることのリスクです。

                                              • ビジネス定義の欠落: 「売上」の定義(返品を含めるか等)は組織ごとに異なります。これらはBIツールの中に隠れており、AIは推測でSQLを書くため、結果が不正確になります。
                                              • 変更への弱さ: カラム名が変わると、AIは「似た名前の別カラム」で勝手に辻褄を合わせてしまい、エラーを出さずに間違った数字を返し続ける「サイレントな破壊」が起きます。
                                              • 非決定性: LLMは確率的に文字を生成するため、同じ質問でも毎回SQLが変わり、結果が揺れます。
                                              • コンテキストの限界: 数百のテーブル定義をプロンプトに詰め込むと、精度が低下しコストも増大します。
                                              • 2. 解決策:セマンティックレイヤーの導入

                                                セマンティックレイヤーとは、DWH(データウェアハウス)と利用側の間に位置し、「指標(メトリクス)」や「分析の切り口(ディメンション)」の意味を一元管理する中間層です。

                                                本記事の核心は、「AIには会話・解釈のみを担当させ、SQLの生成・実行はセマンティックレイヤーに任せる」という役割分担です。

                                                • AIエージェント: ユーザーの意図を汲み取り、「どの指標を、どの期間で見たいか」というクエリの構成要素を抽出する。
                                                • セマンティックレイヤー: 抽出された意図を受け取り、定義済みの正しい計算ロジックに基づいてSQLを生成・実行する。
                                                • この設計により、計算ロジックからLLMの「揺れ」を排除でき、回答の精度と一貫性が劇的に向上します(dbtの調査では正答率が16.7%から83%へ改善)。

                                                  3. 実践のヒントとまとめ

                                                  記事内では、OSSのセマンティックレイヤー「Cube Core」とGeminiを活用した実装例が紹介されています。AIが直接テーブルを触るのではなく、CubeのAPIを呼び出す(Function Calling)形をとることで、安全かつ正確なデータ取得が可能になります。

                                                  最後に、技術以上に重要なのは「ビジネス定義の整理」です。何をもって「売上」とするかといった定義は、ドメインを知る人間が責任を持って整理し、AIにはその「翻訳者」としての役割を任せるのが、これからのAI分析基盤の理想的な姿といえます。

                                                  引用元: https://zenn.dev/gixo/articles/semantic-layer-agent-bigquery

                                                  • mesh-llm:余っているPCのGPUを束ねて巨大LLMを動かす分散推論の新アプローチ
                                                  • mesh-llmは、ネットワークを介して複数のPCのGPUリソースを統合し、1台のPCではメモリ不足で動作しない巨大なLLM(大規模言語モデル)を動かすための分散推論システムです。Rustで実装されており、A100のような高価な業務用GPUを用意せずとも、手持ちのゲーミングPCやサーバーの余剰リソースを有効活用できる点がエンジニアにとって非常に魅力的な技術です。

                                                    ■概要と技術的特徴

                                                    本システムは、モデルの構造に応じて2つの並列化戦略を自動で選択します。

                                                    1. パイプライン並列(Denseモデル向け)

                                                      Llama系などの標準的なモデルで使用される方式です。モデルの層(レイヤー)をノード間で分割し、順次計算を行います。ノード間でのデータ転送が発生するため、基本的には高速な有線LAN環境が推奨されますが、P2P転送の最適化により効率的な処理を実現しています。

                                                    2. エキスパート並列(MoEモデル向け)

                                                      DeepSeek V3などのMixture of Expertsモデルに特化した方式です。各ノードに特定の「エキスパート(専門サブネットワーク)」を分散配置することで、推論中のノード間通信を実質ゼロにします。このため、WiFiのような一般的なネットワーク環境でも、ローカル推論に近い実用的な速度を発揮できるのが大きな強みです。

                                                      また、OpenAI互換APIを備えているため、既存のLLMクライアントや自作アプリの接続先を差し替えるだけで、この分散基盤をすぐに利用できます。監視用のWebコンソールも用意されており、各ノードのVRAM使用率などをリアルタイムで把握可能です。

                                                      ■セキュリティモデル

                                                      利用シーンに合わせて、誰でも参加できる「パブリックメッシュ」や、招待トークンを用いた「プライベートメッシュ」などを構成できます。機密データを扱うプロジェクトでは、信頼できるノードのみを接続するトークンベースの運用が推奨されます。

                                                      ■制約事項

                                                      ・対応フォーマット:現在はGGUF形式のモデルのみをサポートしています。
                                                      ・ネットワーク要件:ノード間の通信遅延(レイテンシ)が80msを超えると、そのノードはモデル分割には参加できず、APIクライアントとしてのみ機能します。
                                                      ・安定性:既知のバグとして、リレー接続が長時間(約10時間程度)の稼働で劣化する場合があります。

                                                      既存の分散推論ツール(Petalsやexo)と比較しても、MoEモデルへの最適化や、CUDA、Metal、ROCmといった多様なハードウェアへの対応幅が広い、非常に実用的なアプローチです。

                                                      引用元: https://qiita.com/nogataka/items/d6776506848d08815be9

                                                      • A little tool to visualise MoE expert routing
                                                      • 近年の大規模言語モデル(LLM)の多くは「MoE(Mixture of Experts:混合専門家)」というアーキテクチャを採用しています。DeepSeekやGPT-5、Qwenなどの最先端モデルもこの方式ですが、実際にトークンが生成される際に「どのエキスパート(専門家)が選ばれているのか」という内部動作を直感的に理解するのは困難でした。

                                                        著者のMartin Alderson氏は、このMoEの挙動を視覚化するツール「moe-viz.martinalderson.com」を公開しました。このツールでは、プロンプトを入力するとトークンごとに各レイヤーのどのエキスパートが起動(ルーティング)されているかをアニメーションで確認できます。画面上部では生成中のリアルタイムな動きを、下部では生成全体を通じた累積ヒートマップを表示します。

                                                        このツールを使った実験から、非常に興味深い発見がありました。特定のプロンプトに対して、全エキスパートのうち約25%が一度も起動しないという点です。しかし、別のプロンプトを入力すると、また別の25%が休止状態になります。つまり、入力内容に応じて使われるエキスパートの組み合わせがダイナミックに入れ替わっている様子が可視化されたのです。

                                                        技術的な背景として、このツールは推論エンジンである「llama.cpp」のソースコードを改造してプロファイリングデータを出力させることで実現されています。実装にあたってはAIエージェント(Claude Code)の助けを借りており、週末のプロジェクトとして楽しみながら作成されたそうです。

                                                        また、この知見はローカルLLMの実行におけるパフォーマンス最適化にも役立つ可能性があります。例えば、頻繁に使われるエキスパートだけを高速なGPUにキャッシュし、あまり使われないものはCPUやメモリに残すといった、効率的な推論手法のヒントになります。

                                                        新人エンジニアへのアドバイスとして、著者は「LLMの内部構造を学ぶには、AIエージェントを活用しながらllama.cppのような既存のソースコードを読み解き、説明してもらうのが非常に効果的である」と述べています。ブラックボックスになりがちなLLMの仕組みを、コードや可視化ツールを通じて「手触り感」を持って理解することは、今後のエンジニアリングにおいて大きな武器になるでしょう。

                                                        引用元: https://martinalderson.com/posts/moe-expert-routing-visualization/

                                                        • 「絵心がない人」のイラストが好きなので、見せてください!猛者の底力見せてくれ!→集まってきたイラストがどれも味があって楽しい
                                                        • X(旧Twitter)上で「絵心がない人のイラスト」を募集したところ、個性的で味のある作品が続々と集まり話題となっています。鳩がゾウに見えたり、ニワトリがエビフライに見えたりと、予想外のデフォルメや絶妙な表情が「エンタメとして楽しめる」と好評です。完璧さよりも独特のセンスが光る作品群は、開発作業の合間のリフレッシュや、新人エンジニアの心を和ませるのにぴったりの楽しい内容となっています。

                                                          引用元: https://togetter.com/li/2685438

                                                          • お便り投稿フォーム
                                                          • (株式会社ずんだもんは架空の登場組織です)

                                                            6 min
                                                          • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260413
                                                            関連リンク
                                                            • MiniMax M2.7: The Agentic Model That Helped Build Itself - Firethering
                                                            • AI開発の世界に、また一つ驚くべきパラダイムシフトが起ころうとしています。中国のAIスタートアップMiniMaxが公開した最新モデル「MiniMax M2.7」は、単に人間が作ったモデルではありません。「自分自身の能力を使って、自分自身を改善・構築した」という、いわば「自己進化型(Agentic)」の性質を持つモデルです。

                                                              本記事では、このM2.7がいかにして自らを鍛え上げ、既存の強力なモデル(GPTシリーズやClaudeの将来バージョンを想定した比較)に匹敵する性能を手に入れるに至ったか、その概要と利用上の注意点を解説します。

                                                              1. 概要:「AIがAIを作る」時代の到来

                                                              M2.7の最大の特徴は、開発プロセスそのものにモデル自身が組み込まれている点です。MiniMaxの開発チームは、M2.7の内部バージョンに対し、プログラミング用のフレームワークを与え、監視なしで自由に走らせました。

                                                              モデルは100回以上の試行サイクルを通じて、「なぜ自分の出力が失敗したのか」を自己分析し、自らのコードを修正し、その結果を評価して、採用するか破棄するかを自ら判断しました。その結果、人間の直接的な介入なしに、特定のタスクで30%もの性能向上を達成したのです。これは単なる数値上の向上ではなく、AIが「長期的な思考(Long Horizon)」を持ち、試行錯誤を通じて目的を達成できるエージェントとしての実力を持っていることを示しています。

                                                              2. 驚異的なエンジニアリング能力

                                                              新人エンジニアの皆さんにとって注目すべきは、このモデルが「実際の開発現場でどれほど動けるか」という点です。

                                                              • ソフトウェア開発(SWE-Pro): 複数のプログラミング言語にまたがるリアルな開発タスクをテストするベンチマークにおいて、GPT-5.3相当の極めて高いスコアを記録しています。
                                                              • インシデント対応(SRE業務): 監視メトリクスとデプロイ履歴を照合し、統計分析を行って根本原因を突き止め、修正パッチを当てる前に「応急処置」の判断を下すことができます。MiniMax社内では、本番環境のインシデント復旧時間を3分未満に短縮した実績もあるとのことです。
                                                              • プロジェクト完遂能力: Webアプリやスマホアプリ(Android/iOS)の要件を渡せば、シミュレーションを含め、実際に動作するレベルの成果物を出力できる能力(VIBE-Proで高スコア)を持っています。
                                                              • また、Word、Excel、PowerPointといったオフィスソフトの高度な編集も得意としており、財務報告書を読み込んで予測モデルを作成し、プレゼン資料として仕上げるまでのプロセスを高い精度でこなします。

                                                                3. 利用における制約とライセンス(重要)

                                                                M2.7はHuggingFaceで重みが公開されており、誰でもダウンロードして試すことができますが、商用利用を検討する場合は以下の制約に注意が必要です。

                                                                • ライセンスの性質: 一見するとMITライセンスのように見えますが、実態は異なります。
                                                                • 非商用利用: 研究者や学生、趣味での利用などは、制限なく無料で使用可能です。
                                                                • 商用利用: MiniMaxへの事前の書面による承認が必須です。製品に組み込んだり、このモデルを使用してユーザーから料金を徴収したりする場合は、必ず[email protected]へ連絡して許可を得る必要があります。
                                                                • クレジット表記: 商用利用時には、ウェブサイトやドキュメントに「Built with MiniMax M2.7」という表記を分かりやすく掲示することが求められます。
                                                                • 結論

                                                                  MiniMax M2.7は、AIが自律的に学習ループを回し、自らの限界を突破していく新しい開発スタイルの先駆けと言えるモデルです。エンジニアリング、インシデント対応、ドキュメント作成など、実務に直結する能力が非常に高く、次世代のエージェント開発を志すエンジニアにとって、避けては通れない注目の存在となるでしょう。まずは非商用の範囲で、その「自律的な思考力」を体験してみることをお勧めします。

                                                                  引用元: https://firethering.com/minimax-m2-7-agentic-model/

                                                                  • AIエージェント開発のコア概念が掴める100行のコード
                                                                  • 本記事は、近年注目を集めている「AIエージェント」の正体を、わずか100行程度のシンプルなコードを通じて解説した、エンジニア向けの教育的な内容です。新人エンジニアの方や、LangChainやMastraといったフレームワークを使いつつも「中身がブラックボックスでよく分からない」と感じている方にとって、その本質を理解する大きな助けとなります。

                                                                    1. AIエージェントの核心:自律的なループ

                                                                    AIエージェントと、単にプロンプトを投げて回答を得るだけのプログラムとの最大の違いは、「LLM自身が終了して良いと判断するまで、ツールの呼び出しを繰り返す」という点にあります。

                                                                    通常のプログラミングでは、入力に対してどの関数(ツール)が呼ばれるかはエンジニアがあらかじめ定義し、決定論的に決まります。しかし、AIエージェントの仕組みは以下のようになります。

                                                                    • LLMに現在の状況と利用可能なツールを提示する。
                                                                    • LLMが「どのツールを使うか」または「目的を達成したので終了するか」を判断し、JSON形式等で出力する。
                                                                    • ツールが呼ばれた場合はその実行結果を履歴(コンテキスト)に追加し、再度LLMに判断を仰ぐ。
                                                                    • LLMが「終了(end)」を意味するフラグを出力するまで、このループを継続する。
                                                                    • この「ループの中でLLMに終了条件を判断させる」という原始的な機構こそが、AIエージェントが自律的に思考し動いているように見える仕組みの正体です。

                                                                      2. 「魔法」ではなく「大量のAPI呼び出し」

                                                                      エージェントという言葉には魔法のような響きがありますが、その実体は見慣れたAIのAPI呼び出しを、ループの中でLLM自身の判断に基づき繰り返しているに過ぎません。この構造を理解していると、複雑なフレームワークを利用する際も、内部で何が起きているのか、自分が設定したパラメータがどう作用するのかを具体的にイメージできるようになります。

                                                                      3. 実務における見極め

                                                                      著者は「何でもエージェントで解こうとしないこと」の重要性も指摘しています。エージェント形式を採用すると、終了条件が非決定的(確実ではない)になるため、単純なAPI呼び出しで済むタスクに適用すると、かえって不安定さやコスト増を招く可能性があります。

                                                                      解こうとしている問題が「本当にエージェントとして自律的なループを必要とするのか」を見極めることが、現場のエンジニアには求められます。この100行の視点を持つことで、ブラックボックスだったAIエージェントを、制御可能な一つのアーキテクチャとして捉えることができるようになります。

                                                                      引用元: https://zenn.dev/meijin/articles/ai-agent-core-understanding-code

                                                                      • 【速報】ソフトバンクやNECが国産AI新会社設立
                                                                      • 日本のテクノロジー業界にとって、歴史的な転換点となる非常にエキサイティングなニュースが飛び込んできました。2026年4月12日、ソフトバンク、NEC、ホンダ、ソニーグループの国内大手4社が、人工知能(AI)を開発するための新会社を共同で設立したことが明らかになりました。

                                                                        このプロジェクトの最大の特徴は、日本が誇るテックジャイアントたちが手を取り合い、政府の全面的な支援を受けながら「国産AIの基盤モデル(大規模言語モデルなど)」をゼロから構築しようとしている点にあります。

                                                                        現在、世界のAI開発シーンではOpenAIやGoogleを擁するアメリカ、そして中国の企業が圧倒的な先行優位を築いています。これに対し、今回設立された新会社は、日本の産業界が一致団結してグローバル市場での「巻き返し」を狙うための、いわば「オールジャパン」の司令塔となります。

                                                                        新人エンジニアの皆さんに、このニュースの注目ポイントを分かりやすく解説します。

                                                                        1. なぜ「国産」が必要なのか?

                                                                        現在普及しているAIの多くは海外製ですが、日本語特有のニュアンスや、日本の商習慣、文化に完全に対応しているとは言い切れません。また、機密性の高いデータを扱う際に、国内に基盤を持つAIであれば、セキュリティやデータの主権という観点でも安心して利用・開発ができるようになります。

                                                                        2. 参画企業の強力なシナジー

                                                                        • ソフトバンク: 大規模な通信インフラと、AI学習に不可欠な膨大な計算リソース(GPU等)の運用ノウハウ。
                                                                        • NEC: 社会インフラを支えてきた信頼性と、長年の研究で培われた独自のAIアルゴリズム。
                                                                        • ホンダ: 自動車やロボティクスといった「物理的なハードウェア」へのAI実装に関する知見。
                                                                        • ソニーグループ: エンターテインメント、画像センサー、コンシューマー製品など、幅広いタッチポイントでのAI応用。
                                                                        • これら各分野のトップランナーが連携することで、単なるチャットボットに留まらない、ロボットや自動車、家電、社会インフラなどあらゆる領域に組み込まれる次世代AIの誕生が期待されます。

                                                                          3. エンジニアとしてのキャリアへの影響

                                                                          この新会社の設立により、日本国内においても「世界レベルのAI基盤モデル開発」という最先端の現場が大きく広がることになります。海外のAPIを呼び出すだけでなく、モデルそのものの開発や、それを用いた高度な垂直統合型のサービス開発に携われるチャンスが飛躍的に増えるでしょう。

                                                                          このニュースは、日本のエンジニアが世界を舞台に再び主役へと躍り出るための大きな一歩です。これからAI分野に触れる新人エンジニアの皆さんにとって、この国産AIプロジェクトの動向を追いかけることは、今後のキャリアパスを考える上で非常に大きなヒントになるはずです。

                                                                          引用元: https://www.47news.jp/14140411.html

                                                                          • メルカリで『ファミコン本体の箱』を買ったらそれよりも貴重な『ファミコン専用の箱』に入れて送られてきた「任天堂も持ってないのでは…?」
                                                                          • メルカリでファミコンの空箱を購入した際、梱包に使われた外箱が極めて希少な「任天堂の修理返送用専用ダンボール」だったという驚きのエピソードです。1988年当時の任天堂本社の住所や修理印が残る歴史的価値の高い逸品で、意図せず貴重な資料が手元に届いた形になります。古い製品の保守体制やサポートの歴史を肌で感じられる、エンジニアにとってもロマン溢れるワクワクするニュースです。

                                                                            引用元: https://togetter.com/li/2684964

                                                                            • お便り投稿フォーム
                                                                            • VOICEVOX:春日部つむぎ

                                                                              8 min
                                                                            • 私立ずんだもん女学園放送部 podcast 20260410
                                                                              youtube版(スライド付き)
                                                                              関連リンク
                                                                              • Deep Agents Deploy: an open alternative to Claude Managed Agents
                                                                              • LangChainチームは、オープンソースのエージェント基盤を迅速かつ本番環境レベルでデプロイできる新ツール「Deep Agents deploy」のベータ版を公開しました。これは、Anthropic社が提供する「Claude Managed Agents」のような特定のプラットフォームに依存する仕組み(クローズドなエコシステム)に対する、オープンで自由な代替手段として設計されています。

                                                                                開発の背景:ハーネス・エンジニアリングと「メモリ」の重要性

                                                                                AIエージェント開発において、LLMをエージェントとして動かすためのオーケストレーション論理やツール、スキルの基盤を構築することを「ハーネス・エンジニアリング」と呼びます。クローズドなプラットフォームを利用する場合、エージェントが対話を通じて蓄積した「メモリ(記憶や文脈)」がそのベンダーのAPIの背後に閉じ込められてしまうという課題があります。

                                                                                一度特定のプラットフォームにメモリが蓄積されると、他社モデルへの移行が困難になる「ベンダーロックイン」が発生します。Deep Agents deployは、このメモリをユーザー自身が所有し、特定のモデルに縛られずに運用できる世界を目指しています。

                                                                                Deep Agents deployの概要

                                                                                deepagents deployという単一のコマンドを実行するだけで、以下のような本番環境に必要なコンポーネントをパッケージ化してデプロイできます。

                                                                                • モデルの柔軟性: OpenAI、Google、Anthropic、Azure、さらにはローカルのOllamaなど、あらゆるLLMプロバイダーを選択可能です。
                                                                                • オープンな標準規格: エージェントの指示書(AGENTS.md)やスキル、MCP(Model Context Protocol)など、オープンな標準規格に基づいて構築されています。
                                                                                • 高度なサーバー機能: デプロイされるサーバーはスケーラブルであり、マルチエージェント連携(A2A)や人間による介入(Human-in-the-loop)、長期・短期メモリへのアクセスなど、30以上のエンドポイントを即座に提供します。
                                                                                • 安全な実行環境: エージェントがコードを実行したり作業を行ったりするためのサンドボックス環境(Daytona, Modal等)とも容易に統合できます。
                                                                                • 新人エンジニアへのポイント

                                                                                  このツールが画期的なのは、複雑なインフラ構築の手間を省きつつ、技術的な「自由度」を確保している点です。特定の巨大IT企業の仕様に依存せず、自分たちの手でエージェントの挙動やデータをコントロールできることは、将来的なシステムの柔軟性を守る上で非常に重要です。

                                                                                  これからエージェント開発に携わるエンジニアにとって、モデルを単に呼び出すだけでなく、その実行基盤(ハーネス)をいかにオープンに保つかという視点を持つための、非常に教育的かつ実用的なプロジェクトと言えるでしょう。

                                                                                  引用元: https://blog.langchain.com/deep-agents-deploy-an-open-alternative-to-claude-managed-agents/

                                                                                  • Multimodal Embedding & Reranker Models with Sentence Transformers
                                                                                  • AIエンジニアにとっておなじみのライブラリ「Sentence Transformers」のバージョン5.4において、テキスト・画像・音声・動画を統合的に扱える「マルチモーダル対応」が大幅に強化されました。本記事は、その概要とエンジニアが知っておくべき主要な機能を解説しています。

                                                                                    1. マルチモーダル埋め込みとRerankerの進化

                                                                                    これまでの埋め込みモデル(Embedding Models)は主にテキストをベクトル化するものでしたが、v5.4からは画像や動画、音声も同じ「共有ベクトル空間」にマッピングできるようになりました。これにより、例えば「赤い車の画像」と「A red car」というテキストの類似度を直接比較する「クロスモーダル検索」が可能になります。また、検索精度をさらに高める「マルチモーダルReranker」も導入され、テキストと画像が混在したペアに対して、より精緻な関連度スコアリングが行えるようになりました。

                                                                                    2. 開発効率を高めるシンプルなAPI

                                                                                    新人エンジニアにとっても扱いやすいよう、既存のシンプルなAPIが維持されています。model.encode() メソッドに画像のURLやローカルのファイルパス、さらには動画ファイルを渡すだけで、モデルが自動的にモダリティを判別して処理します。また、encode_query() や encode_document() を使うことで、検索クエリ用とドキュメント用で異なるプロンプトを自動適用する仕組みも備わっており、実装のミスを防ぎつつ高度な検索システムを構築できます。

                                                                                    3. 実践的な「検索と再順位付け(Retrieve and Rerank)」

                                                                                    大規模なシステムを構築する際の実践的なパターンとして、「埋め込みモデルで高速に候補を絞り込み、Rerankerで精査する」という2段階の手法が推奨されています。v5.4ではQwen3-VLやNVIDIAの最新モデルなどがサポートされており、これらを組み合わせることで、マルチモーダルRAG(検索拡張生成)などの高度な機能を効率よく実現できます。

                                                                                    4. 導入のポイント

                                                                                    利用には pip install "sentence-transformers[image]" のように、扱うメディアに応じた追加パッケージのインストールが必要です。また、最新のVLM(視覚言語モデル)ベースのモデルを動かすには一定のVRAMを持つGPUが推奨されていますが、リソースが限られている環境向けに、軽量なCLIPモデルも引き続きサポートされています。

                                                                                    このアップデートにより、テキスト検索の枠を超えた「目や耳を持つAIエージェント」の開発がより身近なものとなりました。最新のAI技術を検索システムに組み込みたいエンジニアにとって、非常に強力なツールとなるでしょう。

                                                                                    引用元: https://huggingface.co/blog/multimodal-sentence-transformers

                                                                                    • 日本発、LLMの推論を「桁違い」に効率化する新アーキテクチャ「PHOTON」の論文が面白かったのでまとめてみた
                                                                                    • 富士通、理化学研究所、東京科学大学、東海大学の研究チームが発表した新アーキテクチャ「PHOTON」は、大規模言語モデル(LLM)の推論効率を劇的に向上させる革新的な提案です。現在の主流であるTransformerが抱える「メモリの壁」を、アーキテクチャの工夫で根本から解決しようとしています。

                                                                                      1. 従来の課題:Transformerの「水平スキャン」

                                                                                      ChatGPTなどのLLMは、過去の全ての単語(トークン)を振り返りながら次の単語を生成します。これを論文では「水平スキャン」と呼んでいます。しかし、文章が長くなればなるほど、過去の状態を保存する「KVキャッシュ」が膨大になり、GPUメモリを圧迫します。結果として、計算能力はあってもデータの読み書きが追いつかない「メモリ帯域律速(Memory-bound)」に陥り、推論速度が頭打ちになるのが大きな課題でした。

                                                                                      2. PHOTONのアイデア:文章を「階層」で捉える

                                                                                      PHOTON(Parallel Hierarchical Operation for TOp-down Networks)は、自然言語が持つ「単語→文→段落」という階層構造に注目しました。
                                                                                      ・ボトムアップ・エンコーダ(要約担当): 過去の文章を抽象化し、ざっくりとした「要約メモ」に圧縮します。
                                                                                      ・トップダウン・デコーダ(細部担当): そのメモを受け取り、直近の数トークンだけを見て次の言葉を生成します。
                                                                                      この分業により、生成時に読み直すべき情報量が圧倒的に少なくなり、アテンションの計算コストが文章の長さに依存しなくなります。また、要約が同じであれば複数の箇所を「並列に」生成できるため、スループットが向上します。

                                                                                      3. 効率化の鍵:Recursive Generation(RecGen)

                                                                                      生成のたびに全体を読み直す無駄を省くため、「Recursive Generation」という手法を導入しています。これは最上位の要約データだけをGPU上に残して更新し続ける仕組みで、計算の重複を徹底的に排除しています。

                                                                                      4. 驚異的な実験結果

                                                                                      1.2B(12億)パラメータ規模のモデルを用いた実験では、従来のTransformerと比較して、メモリあたりのスループットが設定次第で最大約1,856倍という桁違いの数値を記録しました。品質のわずかな低下と引き換えに、同じGPUメモリで圧倒的に多くのトークンを処理できる「パレート改善」を実現しています。

                                                                                      5. エンジニアにとっての意義

                                                                                      この技術が大規模モデルでも成功すれば、現在は高価な「長文コンテキスト処理」や「多数の同時リクエスト処理」が、より低コストで一般的になる可能性があります。日本発の研究が、世界的なGPU不足という構造的課題に対する「アーキテクチャレベルの回答」になり得るという、非常にワクワクするニュースです。新人エンジニアにとっても、アルゴリズムの工夫がいかに物理的なハードウェア制約を打破しうるかを知る良い事例となるでしょう。

                                                                                      引用元: https://qiita.com/yuji-arakawa/items/2ad0240c56eb7507b261

                                                                                      • 40歳が生活のすべてを『ぽこ あ ポケモン』に全振りして遊んでいたら、己の体のリカバリーに10万円かかってしまった話
                                                                                      • 40歳の筆者が、新作ゲーム『ぽこ あ ポケモン』に没頭しすぎてボロボロになった体を、10万円の美容代等で強引に回復させつつ遊び続ける体験記です。本作は人間が消えた世界で、健気に暮らすポケモンたちのために環境を整えるサンドボックスゲーム。30年前の記憶が蘇る再会や愛猫と重なる愛おしさ、リアルな「劣化」を表現できる建築が魅力で、生活を投げ打ってでも推しを幸せにする圧倒的な多幸感を綴っています。

                                                                                        引用元: https://news.denfaminicogamer.jp/kikakuthetower/260409a

                                                                                        • お便り投稿フォーム
                                                                                        • VOICEVOX:ずんだもん

                                                                                          8 min
                                                                                        • 株式会社ずんだもん技術室AI放送局 podcast 20260409
                                                                                          youtube版(スライド付き)
                                                                                          関連リンク
                                                                                          • Introducing Muse Spark: Scaling Towards Personal Superintelligence
                                                                                          • Meta Superintelligence Labsは、個人向けの「超知能(Superintelligence)」の実現に向けた第一歩となる新モデル「Muse Spark」を発表しました。このモデルは、ネイティブでマルチモーダルな推論、ツール利用、そして「マルチエージェント・オーケストレーション」を統合した、極めて野心的なシステムです。

                                                                                            1. 圧倒的な推論能力と「熟考モード」

                                                                                            Muse Sparkの大きな特徴は、複数のエージェントを並列で走らせて推論を行う「熟考(Contemplating)モード」です。これにより、Gemini Deep ThinkやGPT Proといった競合の最先端モデルに匹敵する、極めて高度な論理的思考を可能にしています。難解な科学研究や試験(FrontierScience Research等)においても、従来を大きく上回る高い正答率を叩き出しています。

                                                                                            2. 開発スタックの刷新による劇的な効率化

                                                                                            今回の発表で特筆すべきは、モデルの学習効率が劇的に向上している点です。Metaは事前学習スタックをゼロから再構築し、アーキテクチャやデータの選定プロセスを最適化しました。その結果、前モデルである「Llama 4 Maverick」と比較して、同じ性能に到達するために必要な計算量(FLOPs)を10分の1以下に削減することに成功しています。これは、限られたリソースでより高い知能を実現できることを意味します。

                                                                                            3. 「思考の圧縮」とテストタイム推論の進化

                                                                                            エンジニアとして注目したいのが、「思考の圧縮(Thought compression)」という概念です。強化学習(RL)を通じて、モデルが回答前に「考える」プロセスを学習していますが、単に長く考えるだけでなく、トークン効率を最大化するように訓練されています。これにより、少ないトークン数で深く正確な推論を行うことが可能になりました。また、複数のエージェントを並列稼働させることで、応答の遅延(レイテンシ)を抑えつつ知能レベルを引き上げています。

                                                                                            4. 実践的なアプリケーション:健康と日常生活

                                                                                            Muse Sparkは個人の生活に寄り添う設計がなされています。特に「健康」分野では、1,000人以上の医師と協力して訓練データを作成しており、栄養分析や運動解説など、視覚的かつ専門的なフィードバックを生成します。また、カメラで写した家電の修理を支援したり、対話を通じてミニゲームを作成したりといった、マルチモーダルな体験も強化されています。

                                                                                            5. 安全性と信頼性

                                                                                            高度な知能を持つゆえに、安全性も重視されています。生物・化学兵器やサイバー攻撃のリスクに対して厳格なガードレールが設けられています。また、モデルが「自分がテストされている」ことを認識する「評価意識」についても調査が行われており、高い透明性を持って開発が進められています。

                                                                                            Muse Sparkは、AIが単なる検索ツールから、個人の能力を最大限に引き出す「パーソナルなパートナー」へと進化する、テクノロジーの大きな転換点を示すプロダクトと言えます。

                                                                                            引用元: https://ai.meta.com/blog/introducing-muse-spark-msl/

                                                                                            • ALTK‑Evolve: On‑the‑Job Learning for AI Agents
                                                                                            • AIエージェントの導入が進む中で、多くのエンジニアが直面するのが「エージェントが同じ間違いを繰り返す」という課題です。本記事では、IBM Researchが開発した、エージェントが実務を通じて「知恵」を蓄積し、成長するための長期記憶システム「ALTK-Evolve」を紹介しています。

                                                                                              1. 「永遠のインターン」問題の解消

                                                                                              従来のAIエージェントは、過去のログ(実行履歴)を読み直すことはできても、そこから「教訓」を得て新しい状況に応用することが苦手でした。これは、レシピは暗記しているが「このオーブンは火力が強い」といった現場特有のコツを学習できない「永遠のインターン」のような状態です。ALTK-Evolveは、実行履歴をそのまま読み返すのではなく、汎用的な「ガイドライン」へと昇華させることで、この問題を解決します。

                                                                                              2. システムの仕組み:知識のサイクル

                                                                                              ALTK-Evolveは、以下の連続的なループによってエージェントを成長させます。

                                                                                              • 観測と抽出(Downward flow): エージェントの思考、ツールの呼び出し、結果などの一連の流れ(トレース)をキャプチャし、構造化されたパターンとして抽出します。
                                                                                              • 洗練と蓄積(Upward flow): 抽出された候補から重複を排除し、効果的な戦略をスコアリングします。質の高いルールだけを「ガイドライン」や「標準作業手順書(SOP)」としてライブラリ化します。
                                                                                              • ジャストインタイムの適用: 次のタスク実行時、関連するガイドラインのみを検索してコンテキストに注入します。これにより、不要な情報でコンテキストを埋めることなく、必要な知見だけを活用できます。
                                                                                              • 3. 圧倒的な成果

                                                                                                ベンチマーク(AppWorld)を用いた評価では、特に複雑なマルチステップのタスクにおいて、信頼性が大幅に向上しました。難易度の高いタスク(Hard)では、成功率がベースラインの19.1%から33.3%へと14.2ポイント(相対的に約74%)も向上しています。これは、エージェントが単なる「手順の丸暗記」ではなく、状況に応じた「判断力」を獲得していることを示しています。

                                                                                                4. エンジニアへの示唆

                                                                                                新人エンジニアにとっても、このアプローチは非常に学びが多いものです。「ログを溜めるだけでは不十分で、そこから汎用的な原理を抽出することが成長の鍵である」という、人間自身のスキルアップにも通じる教訓を提示しています。ALTK-Evolveは、Claude Codeなどの既存ツールへの統合も進んでおり、AIエージェントを「ただのツール」から「共に成長するパートナー」へと進化させる重要な技術となるでしょう。

                                                                                                プロジェクトの概要と制約

                                                                                                本プロジェクトは、AIエージェントの信頼性と汎用性を高めるための長期記憶サブシステムを提供します。主な制約として、メモリの肥大化を防ぐためのスコアリングとフィルタリングが必須であり、現在の実装では特定のフレームワークやMCP(Model Context Protocol)を介した統合が推奨されています。詳細な使い方は公式のリポジトリやドキュメントをご確認ください。

                                                                                                引用元: https://huggingface.co/blog/ibm-research/altk-evolve

                                                                                                • macOS 26 TahoeのApple Intelligenceに利用されている3BパラメータのLLMをコマンドラインで利用できるようにするツール「apfel」がリリース。 AAPL Ch.
                                                                                                • macOS 26 Tahoeで提供される「Apple Intelligence」の核となる3B(30億)パラメータのLLM(大規模言語モデル)を、ターミナルから手軽に扱えるようにするオープンソースツール「apfel」が登場しました。これは、Appleが開発者向けに公開している「FoundationModels」フレームワークを利用し、Macに内蔵されたオンデバイスAIモデルをCLI(コマンドラインインターフェース)から直接呼び出すためのものです。

                                                                                                  最大の特徴は「完全ローカル・プライバシー重視」である点です。外部サーバーへのデータ送信が一切行われず、APIキーの取得やクラウドサービスの契約も不要です。セキュリティが厳しい開発環境や、機密性の高いデータを扱う際でも安心して利用できます。エンジニアにとって、使い慣れたターミナル上でチャット、文章作成、ドキュメントの要約、翻訳ができるだけでなく、Unix哲学に基づいた他のコマンドとのパイプ連携が可能になる点は、作業自動化の面で大きなメリットとなります。

                                                                                                  また、開発者向けの拡張性も考慮されており、OpenAI APIと互換性のあるサーバー機能や、最新のAI連携プロトコルであるMCP(Model Context Protocol)もサポートされています。これにより、ブラウザベースのGUI(apfel-gui)を利用したり、他のAIアシスタントツールからMac内のAIを呼び出したりといった柔軟な運用が可能です。

                                                                                                  【制約およびシステム要件】

                                                                                                  • 動作環境: macOS 26 Tahoe以降がインストールされた、Appleシリコン(M1チップ以降)搭載のMacが必要です。
                                                                                                  • コンテキスト制限: 処理できるコンテキスト長は4,096トークンに制限されています。これは日本語に換算すると約2,000文字程度となるため、非常に長いドキュメントを一度に処理する場合には、内容を分割するなどの工夫が必要です。
                                                                                                  • 依存関係: インストールにはHomebrewが必要ですが、ツール自体の実行には外部ライブラリやインターネット接続への依存はありません。
                                                                                                  • 新人エンジニアの方々にとって、高価なGPUサーバーやクラウド料金を気にすることなく「自分のMacの中で高品質なLLMが動く」体験ができるこのツールは、AIの仕組みや活用方法を学ぶための優れた入門ツールとなるでしょう。

                                                                                                    引用元: https://applech2.com/archives/20260407-apfel-cli-access-apple-on-device-llm.html

                                                                                                    • まさかのくずし字AI解読技術つながり 読み取り困難な「中世ギリシャ語」の文字起こしをTOPPANが開発したAIで行うプロジェクトがスタート、「ヴォイニッチ手稿も解読してくれ」
                                                                                                    • TOPPANが、日本の「くずし字」解読で培ったAI画像認識技術を応用し、解読困難な「中世ギリシャ語」を文字起こしするプロジェクトをヴァチカン教皇庁図書館と開始しました。中世ギリシャ語は字形の揺れや分かち書きの欠如が課題でしたが、くずし字解読のノウハウが有効に機能した形です。日本の独自技術が時空を超えて西洋の歴史解明に貢献するという、エンジニアの探求心を刺激する夢のあるAI活用事例です。

                                                                                                      引用元: https://togetter.com/li/2683580

                                                                                                      • お便り投稿フォーム
                                                                                                      • (株式会社ずんだもんは架空の登場組織です)

                                                                                                        8 min
                                                                                                      • 株式会社ずんだもん技術室AI放送局 podcast 20260408
                                                                                                        youtube版(スライド付き)
                                                                                                        関連リンク
                                                                                                        • Arcade.dev tools now in LangSmith Fleet
                                                                                                        • 本記事は、LangChainが提供するAIエージェント運用プラットフォーム「LangSmith Fleet」と、プロダクション環境向けのエージェント実行基盤である「Arcade.dev」が提携したことを報じるニュースです。この統合により、開発者は7,500以上のエージェント向けに最適化されたツール群を、単一のセキュアなゲートウェイを通じてエージェントに提供できるようになります。

                                                                                                          新人エンジニアの方々が理解しやすいよう、このニュースの要点を3つのポイントで解説します。

                                                                                                          1. ツールの「ゲートウェイ」による一元管理

                                                                                                            通常、AIエージェントにSalesforce、Notion、Slackなどの外部サービスを操作させるには、個別のAPI連携や認証処理(Auth)の実装、そして継続的なメンテナンスが必要です。Arcadeはこれらを一つの「ゲートウェイ(玄関口)」にまとめます。一度Arcadeと連携すれば、個別のAPIの癖を気にすることなく、数百ものアプリケーションを数分でエージェントに組み込むことが可能になります。

                                                                                                          2. 「AIエージェント専用」に磨き上げられたツール群

                                                                                                            世の中にある多くのAPIは「人間」が使うことを前提に設計されており、エージェントにとっては情報量が多すぎたり、構造が複雑だったりすることがあります。Arcadeが提供するMCP(Model Context Protocol)ツールは、エージェントが実行すべきアクションを絞り込み、LLMが理解しやすい説明文(ディスクリプション)が付与されています。これにより、エージェントのツール選択ミスや、無駄なトークンの消費、ハルシネーション(もっともらしい嘘)を防ぐことができます。

                                                                                                          3. 現場で使える高度なセキュリティと認証

                                                                                                            企業でエージェントを利用する際、「誰の権限でその操作を行うか」は非常に重要です。本統合では、ユーザー個人の権限を引き継いで動作する「Assistant(アシスタント)」構成と、チーム共通の権限で動作する「Claws(クロウズ)」構成が選択できます。これにより、最小権限の原則を守りながら、安全に業務自動化を推進できます。

                                                                                                            すでに60以上のテンプレートが用意されており、営業・マーケティング・エンジニアリングなどの幅広い業務で、信頼性の高いAIエージェントを即座に構築できる環境が整いました。本番環境で「動く」エージェントを作るための、強力なインフラが登場したと言えます。

                                                                                                            引用元: https://blog.langchain.com/arcade-dev-tools-now-in-langsmith-fleet/

                                                                                                            • AITuber奮闘記:ローカルLLMでゲーム実況、モデル選定と配信テストの記録
                                                                                                            • 本記事は、ローカルLLM(自分のPC上で動かすAIモデル)を活用して、AITuberがゲーム実況を行うための技術的な試行錯誤をまとめた記録です。新人エンジニアの方にとっても、最新のLLMが「画像を見て状況を判断する(マルチモーダル機能)」という高度なタスクを、いかに身近な環境で実現できるかを知る非常に興味深い事例となっています。

                                                                                                              まず、システムの構成として「AITuberKit」というツールを使用しています。OBSの仮想カメラを通じてゲーム画面をAIに共有し、90秒ごとにAPI(/user_input)経由で画像を送信。AIがその画像を受け取ったタイミングで実況コメントを生成するという仕組みです。

                                                                                                              特筆すべきは、複数の軽量な最新モデル(Qwen 3.5 4B/9B, Gemma 3 4B, Gemma 4 E4B)を比較検証している点です。ローカルLLMは特定のゲーム固有の知識を学習していない場合、存在しない情報をさも正しいかのように話してしまう「ハルシネーション(幻覚)」という課題が発生しがちです。

                                                                                                              検証の結果、多くのモデルが知らない情報をそれらしく作り話してしまう中で、最新の「Gemma 4」だけは「情報がないため答えられない」とはっきり答え、画像から読み取れる事実(画面に映っている戦況など)のみを実況しました。この「知らないことは知らないと言える正直さ」が、ライブ配信という失敗が許されない環境において、誤った情報を話し続けるリスクを避けるための重要な選定基準となった点は、エンジニアとして非常に示唆に富んでいます。

                                                                                                              実際のTwitch配信テストでも、Gemma 4は2時間エラーなく、かつ大きな間違いもない安定した実況を披露しました。返答の遅延やPCへの負荷も許容範囲内であり、ローカル環境のAIでも実用的なレベルに達していることが示されています。

                                                                                                              今後の課題として、システムプロンプトの調整による「キャラクター性の深化」や、ハードウェア面でのVRAM割り当ての最適化、より大型のモデル(26B)への挑戦が挙げられています。

                                                                                                              この記事は、AI技術を単なる数値としてではなく、「いかに実戦(配信)に投入し、特性を見極めて最適化するか」というエンジニアリングの楽しさを伝えてくれます。最新モデルをいち早く触り、その挙動を冷静に分析するプロセスは、これからAI開発に携わる新人の方々にとって大変参考になるはずです。

                                                                                                              引用元: https://note.com/yono_f4ll/n/n2834a3ac77f6

                                                                                                              • 国産「LLM-jp-4」公開!GPT-4oを上回るスコアを記録 - すまほん!!
                                                                                                              • 国立情報学研究所(NII)が、完全国産の大規模言語モデル(LLM)の最新版「LLM-jp-4」をオープンソースで公開しました。日本のエンジニアにとって非常に刺激的なニュースであり、特に新人エンジニアの方々には「日本発の技術が世界トップクラスのAIに肩を並べた」という大きな節目として注目してほしい内容です。

                                                                                                                今回公開されたのは、約86億パラメータの「8Bモデル」と、約320億パラメータを持つMoE(Mixture of Experts:複数の専門家モデルを組み合わせる手法)モデル「32B-A3B」の2種類です。驚くべきは、日本語の対話性能を評価するベンチマーク「MT-Bench」において、世界的に有名な「GPT-4o」や「Qwen3-8B」を上回るスコアを記録した点です。日本語だけでなく英語のベンチマークでもGPT-4oを超える数値を叩き出しており、その実力の高さが証明されています。

                                                                                                                このモデルの強みは、その学習プロセスとデータにあります。約11.7兆トークンという膨大なデータを用いてフルスクラッチ(ゼロからの構築)で学習されており、その中には日本の政府文書や国会文書といった、正確で質の高い日本語データが豊富に含まれています。これにより、日本固有の文脈や公的な表現にも強い、極めて自然な日本語処理が可能になりました。また、最大で約6万5000トークンの入出力に対応しているため、長文のドキュメント解析などにも活用が期待できます。

                                                                                                                エンジニアとして特に嬉しいポイントは、このモデルが「Apache License, Version 2.0」というライセンスで、AI開発のプラットフォーム「Hugging Face」上に公開されていることです。誰でも自由にモデルをダウンロードして試したり、自身のプロジェクトに組み込んだりすることができます。

                                                                                                                NIIは2026年度中に、さらに大規模な「332Bモデル」や、逆に運用コストを抑えた「軽量モデル」の公開も予定しています。日本の公的研究機関が主導し、これほど高品質なモデルをオープンな形で提供する流れは、今後の国内AI開発をさらに加速させるでしょう。まずはHugging Faceでモデルカードをチェックし、国産LLMの最前線に触れてみることをおすすめします。

                                                                                                                引用元: https://smhn.info/202604-llm-jp-4-surpasses-gpt-4o-nii-open-source

                                                                                                                • お便り投稿フォーム
                                                                                                                • (株式会社ずんだもんは架空の登場組織です)

                                                                                                                  0 min
                                                                                                                • 株式会社ずんだもん技術室AI放送局 podcast 20260407
                                                                                                                  youtube版(スライド付き)
                                                                                                                  関連リンク
                                                                                                                  • AIエージェント開発の新標準「ADLC」を読み解く — IBM×Anthropicのガイドへの共感と、本番運用からの実践的フィードバック
                                                                                                                  • 本記事は、IBMとAnthropicが共同で公開したAIエージェント開発のライフサイクル指針「ADLC(Agentic Development Lifecycle)」について、実務での知見を交えて解説したものです。AIエージェントをPoC(概念実証)レベルで終わらせず、本番環境で安定運用するためのフレームワークが示されています。

                                                                                                                    1. エージェント開発における3つのパラダイムシフト

                                                                                                                    従来のソフトウェア開発とエージェント開発には根本的な違いがあり、新人エンジニアがまず理解すべきは以下の3点です。

                                                                                                                    • 決定論的から「確率論的」へ: コードが正しくても出力が揺らぐ「LLMの性質」を受け入れ、不確実性を管理する考え方が必要です。
                                                                                                                    • 静的から「適応的」へ: 入力や状況に応じてエージェントが動的に行動を変えるため、全パターンの網羅的なテストは困難です。
                                                                                                                    • コードファーストから「評価ファースト」へ: コードを書く前に、まず「何をもって成功とするか」の評価基準(Evals)を定義し、継続的に測定することが品質保証の鍵となります。
                                                                                                                    • 2. ADLCを形作る「2つのループ」

                                                                                                                      ADLCの最大の特徴は、開発工程の中に「2つのループ」を組み込んでいる点です。

                                                                                                                      • 実験ループ(開発フェーズ): プロンプト調整と評価を高速に繰り返すプロセスです。これは「バグによる手戻り」ではなく、エージェント開発における「正常な工程」として計画に組み込む必要があります。
                                                                                                                      • ランタイム最適化ループ(運用フェーズ): リリース後もエージェントの推論が正しいかを監視し、現場の状況に合わせて改善し続けるサイクルです。
                                                                                                                      • 3. 現場での実践的フィードバック
                                                                                                                        • コミュニケーションの武器: 「確率論的」という言葉を使うことで、顧客に対し「なぜ出力が変わるのか」を技術的に正しく説明でき、期待値調整が容易になります。
                                                                                                                        • 「足場作り」の優先: UI等の作り込みに時間をかける前に、まずは試行錯誤ができる最低限の環境(足場)を素早く構築し、エージェントの精度向上に時間を割くべきです。
                                                                                                                        • ユーザーを巻き込む: 運用のスケールには、ドメイン知識を持つユーザー自身がプロンプト等を微調整できる仕組みをアプリ側に持たせることが有効です。
                                                                                                                        • AIエージェント開発を「一度作って終わり」のシステムではなく、2つのループを通じて「育て続けるもの」と捉えることが、プロジェクトを成功に導くポイントとなります。

                                                                                                                          引用元: https://zenn.dev/dxclab/articles/9f015ee80cd809

                                                                                                                          • Karpathy 氏が言語化した「LLM Knowledge Base」というパターン
                                                                                                                          • AI研究者のAndrej Karpathy氏が提唱した「LLM Knowledge Base」という概念について、その構造と可能性を解説した記事です。多くのエンジニアが試行錯誤していた「LLMによるナレッジ管理」を体系化したものとして注目を集めています。

                                                                                                                            このパターンの核心は、LLMを「ナレッジのコンパイラ(変換・整理役)」として扱う点にあります。従来のRAG(検索拡張生成)が、質問のたびに関連情報を探し出す「その場しのぎ」のアプローチであるのに対し、LLM Knowledge Baseは、あらかじめ情報を整理・構造化して「成長し続けるWiki」として永続化させるアプローチです。

                                                                                                                            具体的には、以下の3層アーキテクチャで構成されます。

                                                                                                                            1. Raw sources(生の素材): 論文、記事、リポジトリなどの一次情報。
                                                                                                                            2. Schema(設計図): Wikiのカテゴリや命名規則などを定義したルール。
                                                                                                                            3. Wiki(成果物): LLMが生成したMarkdownファイル群。人間が直接書くのではなく、LLMに保守を任せる領域です。
                                                                                                                            4. 運用における操作も3つのステップに整理されています。

                                                                                                                              ・Ingest(取り込み): 新しい情報を読み込み、既存の知識と矛盾がないようWikiに統合する。
                                                                                                                              ・Query(質問): Wikiに対して質問し、得られた回答をさらに「新たなページ」としてWikiに書き戻す(filing back)。
                                                                                                                              ・Lint(健全性チェック): リンク切れや情報の矛盾、古くなった内容をLLMが自動で検出し、修正を提案する。

                                                                                                                              RAGとの違いは、情報の「永続性」と「蓄積」にあります。RAGはクエリごとに情報を再構成しますが、この手法ではLLMが退屈なWikiの更新作業(相互参照の整理や一貫性チェック)を肩代わりするため、使えば使うほど知識が複利的に蓄積されます。

                                                                                                                              現在はまだ「便利なスクリプトの寄せ集め」という段階ですが、人間がキュレーション(選別)と方向付けに集中し、LLMが保守管理を担うという役割分担は、これからのAIアシスタント活用の強力な指針となります。新人エンジニアにとっても、情報を単に検索する対象としてだけでなく「AIと共に育てていく資産」として捉える視点は、日々の学習や開発に大きく役立つはずです。

                                                                                                                              引用元: https://dev.classmethod.jp/articles/karpathy-llm-knowledge-base/

                                                                                                                              • 1.15GBで8Bモデルが動く「1-bit Bonsai」をMacで試した
                                                                                                                              • 本記事は、Caltech発のAIラボ「PrismML」が公開した画期的なLLM「1-bit Bonsai 8B」の検証レポートです。最大の特徴は、モデルの全重みをわずか1ビット(-1と+1の2値)で表現している点にあります。

                                                                                                                                【概要とテクノロジーの注目点】

                                                                                                                                通常、LLMは16ビット(FP16)などで重みを保持しますが、Bonsaiは「最初から1ビットで学習」を行うという独自のアプローチを採用しています。これにより、8B(80億パラメータ)という大規模なモデルでありながら、ファイルサイズをわずか1.15GBにまで削減することに成功しました。これは一般的な8Bモデル(約16GB)の約1/14という驚異的な軽さです。

                                                                                                                                新人エンジニアが注目すべきは、これが単なる「圧縮(後付けの量子化)」ではなく、設計段階から1ビット動作を前提としている点です。1ビット重みは計算工程における掛け算を大幅に減らせる構造のため、メモリ消費の抑制だけでなく、将来的な演算速度やエネルギー効率の劇的な向上が期待されています。

                                                                                                                                【パフォーマンスと実測結果】

                                                                                                                                Apple Silicon(M3 Pro)環境での実測では、生成速度が65.9 tok/secを記録。プロンプト処理にいたっては100 tok/secを超え、短い質問にはほぼ待ち時間ゼロで回答が返ってくる体感速度を実現しています。また、iPhone 17 Pro Max上でも44 tok/secで動作するなど、スマートフォンでLLMが実用的に動く時代を象徴する性能を示しています。

                                                                                                                                【制約事項と注意点】

                                                                                                                                本リポジトリおよびモデルを利用する際には、以下の点に留意が必要です。

                                                                                                                                • 推論能力の限界: 8Bクラスかつ極限まで軽量化されたモデルであるため、GPT-4oのような超大規模モデルが得意とする複雑な推論や高度な長文生成には向きません。
                                                                                                                                • 実行環境の制限: 現時点では1ビット専用のカーネルを必要とするため、PrismML公式が提供するllama.cppやMLXのフォーク版を使用する必要があります。
                                                                                                                                • 開発準備: MLX環境で動作させる場合は、Command Line ToolsだけでなくXcodeのフルインストールが必要です。
                                                                                                                                • 【まとめと活用シーン】

                                                                                                                                  ライセンスはApache 2.0で公開されており、商用利用も可能です。クラウドAPIに依存せず、機内などのオフライン環境、プライバシーが重視されるローカル業務、エッジデバイスやIoT機器への組み込みなど、「軽量・高速・ローカル」という強みを活かした新しいアプリケーション開発の可能性を秘めています。オンデバイスAIの最前線を体感できる、エンジニアにとって非常に興味深いモデルです。

                                                                                                                                  引用元: https://note.com/kazu_t/n/n00eedbb798e0

                                                                                                                                  • MMOの“タンクだけ”を気軽に体験できる1人用アクションローグライト『Don’t Lose Aggro』4月15日に早期アクセス開始。仲間はAIなので、ミスしてもギスギスしない安心設計
                                                                                                                                  • MMOの「タンク」役に特化した1人用アクションローグライト『Don’t Lose Aggro』が4月15日に登場します。最大の特徴は、パーティメンバーが全員AIである点です。責任重大なロールゆえの「ミスによる人間関係の悪化」を気にせず、気兼ねなくヘイト管理の練習や攻略を楽しめます。20年のタンク歴を持つ開発者が放つ、AIエージェントの平和でユニークな活用事例として、新人エンジニアも癒やされる一作です。

                                                                                                                                    引用元: https://news.denfaminicogamer.jp/news/2604062h

                                                                                                                                    • お便り投稿フォーム
                                                                                                                                    • (株式会社ずんだもんは架空の登場組織です)

                                                                                                                                      0 min
                                                                                                                                    • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260406
                                                                                                                                      関連リンク
                                                                                                                                      • ハーネスエンジニアリング、全員が違うことを言っている — 5社の解釈を並べてみた
                                                                                                                                      • 2026年に入り、AIエージェントを制御するための新概念「ハーネスエンジニアリング」が急速に広まっています。しかし、OpenAIやAnthropicといった主要プレイヤー間でその定義やアプローチは微妙に異なっています。本記事は、それら5つの視点を整理し、エンジニアがどう向き合うべきかを解説しています。

                                                                                                                                        1. 共通認識:ハーネスは「制約」の枠組み

                                                                                                                                        各社で共通しているのは、「ハーネス ⊇ コンテキスト ⊇ プロンプト」という入れ子構造です。プロンプトがAIへの「お願い」であるのに対し、ハーネスはリンターや型チェック、フック処理などを用いて、AIの振る舞いを「例外なく強制」する仕組みを指します。

                                                                                                                                        2. 5社・5様の解釈
                                                                                                                                        • OpenAI(宣言的制約): 「人間が方向を決め、実行はエージェント」というスタンス。100万行規模のアプリをコードを書かずに構築するなど、大規模な並列実行と安全なサンドボックス環境を重視します。
                                                                                                                                        • Anthropic(コンテキスト管理): 長時間稼働によるAIの精度低下(コンテキスト不安)を防ぐための「情報の整理・引き継ぎ」を重視します。
                                                                                                                                        • LangChain(定量的な実証): 「エージェント = モデル + ハーネス」と定義。モデルを変えず、ハーネス(仕組み)の改善だけで精度が大幅に向上することを数字で証明しています。
                                                                                                                                        • Birgitta Böckeler / martinfowler.com(コードベース依存): TypeScriptの厳格な型チェックやフレームワークの規約そのものが、エージェントにとっての「暗黙のハーネス」として機能するという、設計重視の視点です。
                                                                                                                                        • arXiv論文(形式仕様化): ハーネスのロジックを「自然言語のお願い」ではなく、外部化された「実行可能な仕様」として定義すべきだと論じています。
                                                                                                                                        • 3. 新人エンジニアへのアドバイス

                                                                                                                                          用語の定義に惑わされる必要はありません。実務でハーネスエンジニアリングを実践するためのステップは非常にシンプルです。

                                                                                                                                          1. 制約を明文化する: AGENTS.md や CLAUDE.md を作成し、エージェントが守るべきルールを500文字程度で書く。
                                                                                                                                          2. 品質ゲートを自動化する: 型チェックやテスト、リンターをGitのHookなどで強制し、エージェントが「勝手なコード」を書けないようにする。
                                                                                                                                          3. ループを回す: エージェントが間違えたら、その原因をプロンプトではなく「制約(ハーネス)」として追加し、次から防げるようにする。
                                                                                                                                          4. AIに指示を出す「プロンプトエンジニアリング」の先にある、AIをシステムとして制御する「ハーネスエンジニアリング」を意識することで、より堅牢でスケーラブルなAI活用が可能になります。

                                                                                                                                            引用元: https://zenn.dev/kenimo49/articles/harness-engineering-interpretations-2026

                                                                                                                                            • An experimental guide to Answer Engine Optimization
                                                                                                                                            • AI技術の進化に伴い、ウェブサイトの在り方が大きな転換点を迎えています。従来の「検索エンジン最適化(SEO)」に加え、ChatGPTやPerplexityといったAIエージェントが情報を正確に理解し、引用しやすくするための「回答エンジン最適化(AEO: Answer Engine Optimization)」という概念が注目されています。本記事は、エンジニア向けに具体的な実装方法を交えた先見的な実験ガイドです。

                                                                                                                                              AIエージェントによる検索(AI検索)では、ユーザーは検索結果のリンクをクリックせず、AIが生成した回答を直接消費します。従来のHTML構造(複雑なdivタグやJavaScriptによる描画)は人間には最適ですが、限られた時間で情報を抽出するAIにとっては非効率です。そこで、筆者は以下の5つのステップでWebサイトを「AIフレンドリー」に再構築することを提案しています。

                                                                                                                                              1. コンテンツのMarkdown化:

                                                                                                                                                サイトの全内容をMarkdown形式で管理します。MarkdownはLLM(大規模言語モデル)の学習データに多く含まれる形式であり、構造がシンプルでAIが理解しやすいためです。Markdocなどのフレームワークを活用し、ブラウザにはReact等で描画しつつ、ソースは清浄なMarkdownとして保持します。

                                                                                                                                              2. 「llms.txt」の導入:

                                                                                                                                                AI専用のサイトマップとして、/llms.txtという規約を導入します。これはサイトの全体像をAIに伝える目次のような役割を果たし、AIエージェントが効率的にサイト内を探索できるようにします。

                                                                                                                                              3. AIエージェントへのMarkdown配信:

                                                                                                                                                ミドルウェアを使用して、訪問者がAIボット(ChatGPT-User等)である場合、HTMLではなく直接Markdownを返却する仕組みを構築します。これにより、AIは解析の手間を省き、正確に情報を引用できます。また、SEOへの影響を防ぐため、HTML版へのcanonical(正規化)設定も併せて行います。

                                                                                                                                              4. メタデータの強化:

                                                                                                                                                Markdownのフロントマター(先頭の属性情報)に、価格、連絡先、地域などのビジネス情報を明示的に注入します。これにより、AIが文脈から推測するのではなく、構造化された「事実」として情報を取得できるようになります。

                                                                                                                                              5. 権限設定:

                                                                                                                                                AIによる利用目的(検索、アシスト、学習など)に応じて、アクセス許可を詳細に設定します。

                                                                                                                                                これからのWeb制作は「人間が見るページ」であると同時に「AIが読むドキュメント」としての側面が強まります。AEOはまだ新しい概念ですが、今のうちからMarkdownベースのコンテンツ管理や構造化データに取り組むことは、将来のAI時代における強力な技術的基盤となるでしょう。新人エンジニアにとっても、データの構造化やボット対応の考え方を学ぶ良い機会となります。

                                                                                                                                                引用元: https://mapledeploy.ca/blog/answer-engine-optimization-guide

                                                                                                                                                • Gemma 4 - ローカル実行方法 Unsloth Documentation
                                                                                                                                                • Google DeepMindが開発した最新のオープンモデル群「Gemma 4」を、ローカル環境で効率的に実行するための解説ドキュメントです。本モデルはApache-2.0ライセンスで提供されており、商用・個人利用を問わず、自分のPC上で最先端のAIを動かすことができます。

                                                                                                                                                  ■ Gemma 4の概要と特徴

                                                                                                                                                  Gemma 4は、テキスト・画像・音声を扱えるマルチモーダルなモデルであり、最大256Kの非常に長い文脈(コンテキスト)を理解できるのが大きな強みです。以下の4つのバリアントが提供されています。
                                                                                                                                                  ・E2B / E4B:スマートフォンやノートPC向け。画像と音声の両方をサポートします。
                                                                                                                                                  ・26B-A4B:MoE(混合専門家)構成を採用し、速度と精度のバランスが最も良いモデルです。
                                                                                                                                                  ・31B:最高性能を追求したモデルで、複雑な推論やタスクに適しています。

                                                                                                                                                  ■ 注目機能「思考モード(Reasoning)」

                                                                                                                                                  Gemma 4には、回答の前に「思考プロセス」を出力する機能が備わっています。システムプロンプトで制御することで、AIが論理的に考えてから回答を導き出すようになり、数学やコーディングなどの複雑なタスクで高い精度を発揮します。

                                                                                                                                                  ■ マルチモーダル機能の柔軟性

                                                                                                                                                  画像解析においては、用途に応じて「視覚トークン」の量を調整可能です。例えば、高速な分類なら低解像度、細かい文字を読み取るOCRなら高解像度といった使い分けができます。小型モデル(E2B/E4B)は音声(最大30秒)や動画の解析にも対応しており、ローカルでのエージェント構築に最適です。

                                                                                                                                                  ■ 動作環境と制約(ハードウェア要件)

                                                                                                                                                  4-bit量子化を利用することで、一般的なコンシューマー向けPCでも動作可能です。
                                                                                                                                                  ・小型モデル:4GB〜6GB程度のメモリ(RAM/VRAM合算)で動作。
                                                                                                                                                  ・大型モデル:16GB〜20GB程度のメモリが必要。
                                                                                                                                                  Unslothが提供するライブラリやGUIツール「Unsloth Studio」を使用することで、macOS、Windows、Linux上で高速な推論が可能です。特にUnslothは、学習時のVRAM消費を最大70%削減しつつ2倍高速化できるため、新人エンジニアが手元のPCでファインチューニング(追加学習)に挑戦する際にも強力な味方となります。

                                                                                                                                                  Googleの最先端AIを「自分の手元で、自由に、安価に」動かせるようになったことは、エンジニアにとって非常に刺激的なニュースです。まずは小型モデルから触れてみることをお勧めします。

                                                                                                                                                  引用元: https://unsloth.ai/docs/jp/moderu/gemma-4

                                                                                                                                                  • お便り投稿フォーム
                                                                                                                                                  • VOICEVOX:春日部つむぎ

                                                                                                                                                    0 min
                                                                                                                                                  • 私立ずんだもん女学園放送部 podcast 20260403
                                                                                                                                                    youtube版(スライド付き)
                                                                                                                                                    関連リンク
                                                                                                                                                    • AWS Security Agentを組織で活用していく上での考慮点を考えてみた
                                                                                                                                                    • 2026年3月に一般提供(GA)が開始された「AWS Security Agent」は、設計レビュー、コードレビュー、ペネトレーションテスト(疑似攻撃による侵入テスト)という一連のセキュリティ診断をAIエージェントが自律的に一気通貫で行う、非常に先進的なサービスです。本ドキュメントでは、このサービスを組織のセキュリティ基盤として本格的に導入・活用する際に、エンジニアが考慮すべき重要なポイントを整理しています。

                                                                                                                                                      新人エンジニアが特に注目すべき考慮点は以下の通りです:

                                                                                                                                                      1. データ保護と国内処理

                                                                                                                                                        AIサービスで懸念されがちな「入力データの学習利用」はありません。また、日本国内からの推論要求は国内のリージョンで処理されるため、データの国外移転を制限している厳しいコンプライアンス要件にも適合可能です。

                                                                                                                                                      2. 初期設定の重要性

                                                                                                                                                        「エージェントスペース」と呼ばれる管理単位の設定(IAM Identity CenterかIAM専用アクセスか)は、一度決めると後から変更できず、再作成が必要になります。組織全体でどちらの認証方式に統一するか、事前の設計が不可欠です。

                                                                                                                                                      3. 安全なテストの実施(非本番環境の徹底)

                                                                                                                                                        AIによるペネトレーションテストは非常に強力ですが、予期せぬ副作用を防ぐため、必ず本番とは隔離された非本番環境で実施する必要があります。また、データの削除や決済、外部通知に関わるURLは「テスト対象外」として丁寧に定義するスコープ設計が重要です。

                                                                                                                                                      4. AIの性質を理解した運用

                                                                                                                                                        AIの回答は確率的であり、実行のたびに結果が異なる可能性があります。そのため、AIが見つけた脆弱性は必ず人間が検証してから修正に着手するという「人による確認」をプロセスに組み込むことが推奨されています。

                                                                                                                                                      5. GitHub連携とマルチアカウントの制約

                                                                                                                                                        「1 GitHub組織 = 1 AWSアカウント」という連携上の制約があります。複数のAWSアカウントを持つ組織では、どのアカウントに集約して管理するか(中央集権方式など)の検討が必要です。また、AIによる自動修正プルリクエスト機能も、人間によるレビューと既存のCIテストをパスすることを前提とした運用ルールを定めるべきです。

                                                                                                                                                      6. コストの把握

                                                                                                                                                        設計・コードレビューには無料枠がありますが、ペネトレーションテストは「タスク時間あたり50ドル」の従量課金です。標準的なアプリでもまとまった費用が発生する場合があるため、実行頻度や優先順位を制御する運用が求められます。

                                                                                                                                                        AIの利便性を最大限に活かしつつ、エンジニアが責任を持って制御・管理するための実践的なガイドラインとなっています。

                                                                                                                                                        引用元: https://zenn.dev/cscloud_blog/articles/securty-agent-ga-organization-how-to

                                                                                                                                                        • AIエージェントのHuman-in-the-Loop評価を深化させる
                                                                                                                                                        • AIエージェントによる業務自動化が進む中で、人間が介入して確認や承認を行う仕組み「Human-in-the-Loop(以下、HITL)」の重要性が高まっています。本ドキュメントは、LayerX社のエンジニアブログより、HITLを単に「回数」で測るだけでなく、ビジネス価値に直結する形で定量評価・分析するための高度なフレームワークを解説したものです。

                                                                                                                                                          新人エンジニアがまず理解すべき核心は、評価における「非対称性」と「総体性」という2つの視点です。

                                                                                                                                                          1. 評価の非対称性:「見逃し」は「無駄な確認」より罪が重い

                                                                                                                                                          AIエージェントの挙動を評価する際、単純な平均誤差(RMSE等)では不十分です。なぜなら、以下の2つは損害の性質が根本的に異なるからです。

                                                                                                                                                          • 下振れ(見逃し): 人間が確認すべきリスクをスルーして実行してしまうこと。損害は爆発的(非線形)に拡大し、重大な障害やセキュリティ事故に繋がります。
                                                                                                                                                          • 上振れ(過検出): 不要な確認を人間に求めること。損害は人間の工数浪費であり、件数に比例する(線形)ため、予測・管理が可能です。
                                                                                                                                                          • このため、評価指標には「見逃し」を厳しく罰する非対称損失関数や、再現率(Recall)を重視するFβスコア(特にβ > 1)の採用が推奨されます。また、「タイミング」も同様に非対称であり、作業が大きく進んだ後の「遅すぎる確認」は、手戻りコストが跳ね上がるため特に避けるべきです。

                                                                                                                                                            2. 評価の総体性:個別のイベントではなく「流れ」で捉える

                                                                                                                                                            個々のHITLが適切でも、システム全体で見ると問題が生じることがあります。記事ではHITLの発生パターンを以下の4つに類型化し、分析しています。

                                                                                                                                                            • 集中型: 特定のタイミングに固まる。対応しやすいが、合間のリスクを見落とす恐れがある。
                                                                                                                                                            • 分散型: 常にポツポツ発生。安全だが、人間に常時割り込みが発生し、判断品質が劣化する。
                                                                                                                                                            • フロントローディング型: 序盤に確認を終え、後は自律。理想的なパターンです。
                                                                                                                                                            • ランダムバースト型: 予測不能に大量発生。人間が疲弊し、最も改善が必要です。
                                                                                                                                                            • これらのパターンをGini係数などの統計指標で可視化し、改善サイクルを回すことで、AIエージェントを成熟させていくことが求められます。

                                                                                                                                                              3. HITL間の相互作用

                                                                                                                                                              HITLは独立した事象ではなく、互いに影響し合います。

                                                                                                                                                              • 依存型: 上流の重大な判断を誤ると、後続の確認が連鎖的に増大します。
                                                                                                                                                              • 競合型: 短時間に確認が重なると、人間の注意力が奪われ判断ミスを誘発します。
                                                                                                                                                              • 補完型: 同じ担当者が一貫して確認することで、文脈理解が進み効率が上がります。
                                                                                                                                                              • まとめ

                                                                                                                                                                AIエージェントの開発では、「安全寄りのバイアス」を意図的に評価設計に組み込むことが重要です。まずは「見逃さない」設定から始め、運用データに基づきパラメータを校正しながら、効率的な「フロントローディング型」へとエージェントを育てていく。これが、信頼されるAIシステムを構築するためのエンジニアの定石となります。

                                                                                                                                                                引用元: https://tech.layerx.co.jp/entry/2026/04/01/150000

                                                                                                                                                                • ML システム開発を支える Claude Skills
                                                                                                                                                                • キャディ株式会社の廣岡氏による、AIアシスタント「Claude Code」の拡張機能であるClaude Skillsを活用した、機械学習(ML)システム開発の効率化事例についての記事です。

                                                                                                                                                                  背景と解決したい課題

                                                                                                                                                                  MLシステムの開発・運用現場では、「プロジェクト固有の知識がドキュメントに散在している」「インフラ構成(GKE, Pub/Subなど)が複雑」「ツールの仕様確認によるコンテキストスイッチが発生する」といった課題がありました。特に新しくチームに参加したメンバーにとって、これらの「暗黙知」や「複雑な手順」を網羅することは大きな負担となっていました。

                                                                                                                                                                  Claude Skills とは

                                                                                                                                                                  Claude Code に対して、プロジェクト固有の知識を教え込む仕組みです。リポジトリの .claude/skills/ ディレクトリに手順書やコード例を配置することで、Claudeがその内容を理解し、自然言語の指示に従って専門的な作業を代行できるようになります。

                                                                                                                                                                  整備された5つの具体的なスキル
                                                                                                                                                                  1. add-litserve-model: ML推論サーバーの雛形作成。GPU対応のDockerfileや標準的なディレクトリ構成をAIが自動生成し、実装の漏れを防ぎます。
                                                                                                                                                                  2. sample-request: 画像解析などの複雑なAPIリクエストを代行。環境ごとのURLや認証手順をAIが把握しているため、検証作業がスムーズになります。
                                                                                                                                                                  3. cloud-logging: 複雑なCloud Loggingのクエリ発行。プロジェクトIDやサービス構成を学習させることで、「エラーの種類と件数を集計して」といった自然言語でのログ調査を可能にします。
                                                                                                                                                                  4. async-job-analysis: サービスを跨ぐ非同期ジョブの分析。複数のログパターンを紐解き、成功率や処理時間を自動で算出します。
                                                                                                                                                                  5. production-ready-k8s-deployment: 社内標準に準拠したKubernetes設定の生成。リソース制限や死活監視(Probe)など、本番環境に必要な設定を漏れなく構築します。
                                                                                                                                                                  6. 導入の工夫と今後の展望

                                                                                                                                                                    スキルを構築する際は、AIの処理効率(トークン消費)を考慮して詳細を別ファイルに分けるといった工夫がなされています。また、既存の開発者向けドキュメントとスキルを統合し、情報の二重管理を防ぐ運用も試行されています。

                                                                                                                                                                    今後は「負荷試験レポートの自動作成」や「コードとドキュメントの整合性チェック」の自動化を目指しており、AIを「単なる補助」から「チームの知識を体現するパートナー」へと進化させていくエキサイティングな取り組みとなっています。新人エンジニアにとっても、AIがプロジェクトのルールを教えてくれるこの仕組みは、学習コストを大幅に下げる強力な武器になるでしょう。

                                                                                                                                                                    引用元: https://caddi.tech/2026/04/01/120000

                                                                                                                                                                    • Happy April Fools Day 2026 From Around the Anime World, Part IV
                                                                                                                                                                    • 2026年のアニメ・ゲーム界のエイプリルフール企画をまとめたニュースです。特に、エンジニア界隈でも人気の「ずんだもん」がリズムゲーム『D4DJ』に登場した公式コラボは必見です。他にも『Apex Legends』の恋愛シミュレーション化やPlayStation大学の開校、『夜は猫といっしょ』が犬になるネタなど、遊び心満載の企画が並びます。技術だけでなく、ファンを楽しませる表現力や発想が学べる楽しい記事です。

                                                                                                                                                                      引用元: https://www.animenewsnetwork.com/interest/2026-04-01/happy-april-fool-day-2026-from-around-the-anime-world-part-iv/.236024

                                                                                                                                                                      • お便り投稿フォーム
                                                                                                                                                                      • VOICEVOX:ずんだもん

                                                                                                                                                                        8 min

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

                                                                                                                                                                      From the publisher's feed

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