Description

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に保守を任せる領域です。

運用における操作も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

• お便り投稿フォーム

（株式会社ずんだもんは架空の登場組織です）