Episodes

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

    株式会社ずんだもん技術室AI放送局 podcast 20260407
    Apr 6 2026
    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層アーキテクチャで構成されます。 Raw sources（生の素材）: 論文、記事、リポジトリなどの一次情報。Schema（設計図）: Wikiのカテゴリや命名規則などを定義したルール。Wiki（成果物）: LLMが生成したMarkdownファイル群。人間が直接書くのではなく、LLMに保守を任せる領域です。 運用における操作も3つのステップに整理されています。 ・Ingest（取り込み）: 新しい情報を読み込み、既存の知識と矛盾がないようWikiに統合する。 ・Query（質問）: Wikiに対して質問し、得られた回答をさらに「新たなページ」としてWikiに書き戻す（filing back）。 ・Lint（健全性チェック）: リンク切れや情報の矛盾、古くなった内容をLLMが自動で検出し、修正を提案する。 RAGとの違いは、情報の「永続性」と「蓄積」にあります。RAGはクエリごとに情報を再構成しますが、この手法ではLLMが退屈なWikiの更新作業（...
    Show More Show Less
    Less than 1 minute
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260406

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260406
    Apr 5 2026
    関連リンク ハーネスエンジニアリング、全員が違うことを言っている — 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. 新人エンジニアへのアドバイス 用語の定義に惑わされる必要はありません。実務でハーネスエンジニアリングを実践するためのステップは非常にシンプルです。 制約を明文化する: AGENTS.md や CLAUDE.md を作成し、エージェントが守るべきルールを500文字程度で書く。品質ゲートを自動化する: 型チェックやテスト、リンターをGitのHookなどで強制し、エージェントが「勝手なコード」を書けないようにする。ループを回す: エージェントが間違えたら、その原因をプロンプトではなく「制約（ハーネス）」として追加し、次から防げるようにする。 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フレンドリー」に再構築することを提案しています。 コンテンツのMarkdown化: サイトの全内容をMarkdown形式で管理します。MarkdownはLLM（大規模言語モデル）の学習データに多く含まれる形式であり、構造がシンプルでAIが理解しやすいためです。Markdocなどのフレームワークを活用し、ブラウザにはReact等で描画しつつ、ソースは清浄なMarkdownとして保持します。 「llms.txt」の導入: AI専用のサイトマップとして、/llms.txtという規約を導入します。これはサイトの全体像をAIに伝える目次のような役割を果たし、AIエージェントが効率的にサイト内を探索...
    Show More Show Less
    Less than 1 minute
  • 私立ずんだもん女学園放送部 podcast 20260403

    私立ずんだもん女学園放送部 podcast 20260403
    Apr 2 2026
    youtube版(スライド付き) 関連リンク AWS Security Agentを組織で活用していく上での考慮点を考えてみた 2026年3月に一般提供（GA）が開始された「AWS Security Agent」は、設計レビュー、コードレビュー、ペネトレーションテスト（疑似攻撃による侵入テスト）という一連のセキュリティ診断をAIエージェントが自律的に一気通貫で行う、非常に先進的なサービスです。本ドキュメントでは、このサービスを組織のセキュリティ基盤として本格的に導入・活用する際に、エンジニアが考慮すべき重要なポイントを整理しています。 新人エンジニアが特に注目すべき考慮点は以下の通りです： データ保護と国内処理 AIサービスで懸念されがちな「入力データの学習利用」はありません。また、日本国内からの推論要求は国内のリージョンで処理されるため、データの国外移転を制限している厳しいコンプライアンス要件にも適合可能です。 初期設定の重要性 「エージェントスペース」と呼ばれる管理単位の設定（IAM Identity CenterかIAM専用アクセスか）は、一度決めると後から変更できず、再作成が必要になります。組織全体でどちらの認証方式に統一するか、事前の設計が不可欠です。 安全なテストの実施（非本番環境の徹底） AIによるペネトレーションテストは非常に強力ですが、予期せぬ副作用を防ぐため、必ず本番とは隔離された非本番環境で実施する必要があります。また、データの削除や決済、外部通知に関わるURLは「テスト対象外」として丁寧に定義するスコープ設計が重要です。 AIの性質を理解した運用 AIの回答は確率的であり、実行のたびに結果が異なる可能性があります。そのため、AIが見つけた脆弱性は必ず人間が検証してから修正に着手するという「人による確認」をプロセスに組み込むことが推奨されています。 GitHub連携とマルチアカウントの制約 「1 GitHub組織 ＝ 1 AWSアカウント」という連携上の制約があります。複数のAWSアカウントを持つ組織では、どのアカウントに集約して管理するか（中央集権方式など）の検討が必要です。また、AIによる自動修正プルリクエスト機能も、人間によるレビューと既存のCIテストをパスすることを前提とした運用ルールを定めるべきです。 コストの把握 設計・コードレビューには無料枠がありますが、ペネトレーションテストは「タスク時間あたり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）の採用が推奨されます。また、「タイミング」も同様に非対称であり、作業が大きく進んだ後の「遅すぎる確認」は、手戻りコストが跳...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20260402

    株式会社ずんだもん技術室AI放送局 podcast 20260402
    Apr 1 2026
    youtube版(スライド付き) 関連リンク Holo3: Breaking the Computer Use Frontier 本記事は、自律型エンタープライズの実現を目指すH社が発表した、コンピュータ操作（Computer Use）に特化した最新AIエージェント「Holo3」の紹介記事です。Holo3は、デスクトップPCの操作能力を測る主要ベンチマーク「OSWorld-Verified」において、78.85%という業界最高水準のスコアを達成し、既存の巨大なプロプライエタリ・モデルを凌駕する性能を示しました。 【技術的な核心：Agentic Learning Flywheel】 Holo3の強みは、モデルの「知覚」と「意思決定」を継続的に磨き上げる「Agentic Learning Flywheel（エージェント学習の弾み車）」という特殊なトレーニングパイプラインにあります。 合成ナビゲーションデータ：人間とAIの指示に基づき、多様な操作例を生成。ドメイン外拡張：未知のUIや予期せぬ挙動にも対応できるよう、プログラムを用いてシナリオを増幅。厳選された強化学習（Curated RL）：高度なフィルタリングを経たデータを用いた強化学習により、タスク実行の精度を最大化しています。 【実用性を支える「合成環境工場」と評価指標】 開発チームは、現実の企業システムを模した環境を自動生成する「Synthetic Environment Factory」を構築しました。コーディングエージェントがウェブサイトをゼロから構築し、そこで複雑なタスクをエージェントに実行させることで、実務に近い訓練を行っています。 さらに、独自の評価指標「H Corporate Benchmarks」を導入。これは、PDFから備品の価格を取得し、予算と照らし合わせ、個別に対象者へメールを送るといった、複数のアプリケーションを跨ぐ高度な推論と持続的な作業が必要な486のタスクで構成されています。 【効率的なモデル構成とオープン化】 Holo3-122B-A10Bは、122B（1220億）の総パラメータを持ちつつ、実行時に動くのは10B（100億）という効率的なアーキテクチャを採用しています。これにより、GPT 5.4やOpus 4.6といった超巨大モデルに比べて遥かに低コストで運用可能です。また、より軽量な「Holo3-35B-A3B」はApache 2.0ライセンスでオープン公開されており、誰でも利用・開発が可能です。 【新人エンジニアへのメッセージ】 「AIがPCを操作する」技術は、単なる自動化から、未知のソフトウェアをリアルタイムで学習・操作する「Adaptive Agency（適応型エージェント）」の段階へ進化しようとしています。Holo3のように軽量で高性能なオープンモデルが登場したことで、特定の業務に特化したエージェントを自分たちで構築・改善できるエキサイティングな時代が到来しています。最先端のベンチマーク手法や、合成データを用いた学習サイクルを理解することは、これからのエンジニアにとって大きな武器になるはずです。 引用元: https://huggingface.co/blog/Hcompany/holo3 Ubieにおける一年間のセキュリティ分析AIエージェントの運用 Ubie社が約1年間にわたり運用してきた、セキュリティ分析AIエージェント「Warren」の実践的な知見をまとめたドキュメントです。新人エンジニアの方にとっても、生成AIを実際の業務フローに組み込む際の「一歩進んだ活用術」として非常に参考になる内容です。 ■ セキュリティ分析とAIエージェント「Warren」 セキュリティ分析とは、EDRや脆弱性スキャナーなどのツールが検知した膨大な「アラート」を調査し、それが「本当に危険な攻撃（真の陽性）」か、あるいは「正当な業務による誤検知（偽陽性）」かを判断する業務です。従来は熟練のエンジニアが数十分かけてログを検索し、文脈を読み解く必要がありました。 これに対し、Ubieが開発した「Warren」は、Claudeなどの高性能なLLMを搭載したAIエージェントです。単なる要約ツールではなく、自らツールを使いこなして調査を完結させる能力を持っています。 ■ AIエージェント運用のメリット 圧倒的な情報収集スピード: AIはBigQueryへのクエリ実行、EDRのAPI連携、Slackの履歴検索、GitHub上のコード確認などを数分で並列実行します。人間が「どこに情報があったか」を思い出す手間をすべて代行し、認知負荷を大幅に下げてくれます。人間を超える誤検知の判定: 社内環境やログの詳細を突き合わせることで...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだどん技術室AI放送局 podcast 20260401

    株式会社ずんだどん技術室AI放送局 podcast 20260401
    Mar 31 2026
    youtube版(スライド付き) 関連リンク Claude Codeの/loopで自律的にパフォーマンスチューニングのPDCAを回させる仕組みを作った【autoresearch】 本記事は、AIエージェントにプログラムの改善を自律的に繰り返させる「autoresearch」という手法を、サーバーサイド（Rails）のパフォーマンス改善に応用した実践記録です。開発者が寝ている間もAIが試行錯誤を繰り返し、レスポンスタイムを自動で短縮し続ける仕組みを構築しています。 1. 「autoresearch」の仕組みと3つの原則 元ネタは、AIに自身の訓練コードを修正・実行・評価させることで性能を向上させるプロジェクトです。これをサーバーサイド開発に転用するにあたり、以下の3つの原則を定義しています。 固定された評価基準: AIが改ざんできないベンチマークスクリプトと評価関数を用意し、公正に比較する。固定された時間予算: 1サイクルの時間を一定（例：10分）に制限し、小さな改善を積み重ねる圧力をかける。進化的選択圧: 改善すれば採用（Keep）、改悪なら破棄（Discard）。常に最良の状態から次の試行を開始する。 2. Claude Codeを活用した自律ループの実装 Claude Codeのスキル機能と/loopコマンドを組み合わせ、「コード分析 → 実装 → テスト実行 → ベンチマーク計測 → 判定・記録」というPDCAサイクルを自動化しています。これにより、エンジニアが介在することなく、数十回の実験を自律的に走らせることが可能になりました。 3. AIを暴走させない「ハーネスエンジニアリング」 AIに自律的な権限を与えるため、安全性を確保する「手綱（ハーネス）」の設計が重要視されています。 テストデータの隔離: 「チューニング用AI」と「データ準備用AI」を分離。チューニング用AIにテストデータの中身を見せないことで、特定データに特化した不正な最適化（過学習）を防ぎます。フック機能によるツール制限: Claude Codeのツール実行（ファイルの読み取りやコマンド実行）を監視し、ホワイトリスト方式で許可された安全なコマンドのみを実行できるように制限しています。ブランチ保護: 作業用の特定ブランチ以外では動作しないよう制限し、メインのコードベースを守ります。 まとめ：エンジニアの新たな役割 これからのエンジニアは、自らコードを書くだけでなく、「AIが安全かつ自律的に動くための行動原理と環境」を設計することが重要なスキルになります。本記事の実践は、AIエージェントと共に開発を進める次世代のソフトウェアエンジニアリングの姿を示しています。新人エンジニアにとっても、AIを単なる「チャット相手」ではなく「自律的なチームメンバー」として使いこなすための非常に示唆に富む内容です。 引用元: https://zenn.dev/dely_jp/articles/3117e590465e38 Announcing the LangChain + MongoDB Partnership: The AI Agent Stack That Runs On The Database You Already Trust AIアプリケーション開発で広く使われる「LangChain」と、クラウドデータベースの「MongoDB」が戦略的パートナーシップを発表しました。この提携は、AIエージェントをプロトタイプ（試作）からプロダクション（本番運用）へとスムーズに移行させるための「AIエージェント・スタック」を提供することを目的としています。 背景：本番環境におけるエージェント開発の課題 AIエージェントを実際のビジネス現場で動かすには、単にモデルに指示を出すだけでは不十分です。 クラッシュしても続きから再開できる「永続的なメモリ（記憶）」企業の膨大なデータから必要な情報を探す「検索機能（RAG）」データベース内の構造化データへのアクセス何が起きたかを分析できる「デバッグや監視の仕組み」 これらを実現するために、従来は複数の異なるシステムを組み合わせて同期させる必要があり、インフラが非常に複雑になるという課題がありました。 今回の統合が提供する主な機能 今回の提携により、MongoDB AtlasをAIエージェントの包括的なバックエンドとして利用できるようになります。 Atlas Vector Searchの統合: ベクトル検索がLangChainにネイティブ対応しました。運用データと同じ場所でベクトル検索ができるため、データの同期の手間が省け、セキュリティ管理も一本化できます。...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20260331

    株式会社ずんだもん技術室AI放送局 podcast 20260331
    Mar 30 2026
    youtube版(スライド付き) 関連リンク 定常業務を自動操縦にする — Claude Code スケジューラーの育て方 本記事は、AIエンジニアリングツール「Claude Code」の新機能であるスケジューラーを活用し、日々のルーチンワークを自動化して「タスクを覚えておくストレス」を解消する運用ノウハウを解説したものです。特に、細かな事務作業に追われがちなエンジニアやマネージャーにとって、業務効率を劇的に改善するヒントが詰まっています。 スケジューラーの3つの実行環境 Claude Codeには、用途に応じた3つのスケジューラーが用意されています。 /loop: セッション内の一時的な自動化。デプロイ監視などに適しています。Desktop: 自分のPC上で実行。実行中にプロンプトの微調整ができるため、開発中のタスクに最適です。Cloud: Anthropicのクラウド上で実行。PCを閉じていても定時に実行されるため、安定したタスクの完全自動化に向いています。 なぜ強力なのか：MCPとの連携 最大の特徴は、MCP（Model Context Protocol）を通じて、Slack、Notion、GitHub、Google Calendarなどの外部ツールとノンコーディングで連携できる点です。従来のツールでは個別のAPI連携コードを書く必要がありましたが、Claude Codeなら「カレンダーから予定を取り、GitHubの活動をまとめてSlackに送る」といった横断的な処理を、自然言語のプロンプトだけで定義できます。 具体的な自動化の例 記事では、以下のような実用的なワークフローが紹介されています。 1on1準備: メンバーのGitHubやSlackの活動を自動収集し、面談用サマリーを作成。議事録生成: MTG後に内容を整形してNotionへ保存し、Slackへ要約を投稿。日次レポート: 前日のTODOと当日の予定を突き合わせ、報告書を自動作成。自動化提案: 自分の活動記録をAIが分析し、次に自動化すべき作業を提案。 成功の秘訣：「Desktopで育ててCloudに昇格」 いきなり完全自動化（Cloud）を目指すと、予期せぬエラーや低品質な出力が発生しやすくなります。まずはDesktopスケジューラーで実際に動く様子を確認しながらプロンプトを微調整し、3回以上連続で期待通りの結果が出せるようになってからCloudへ移行するという、段階的な「育成」アプローチが推奨されています。 まとめ 自動化の目的は、単なる時短ではなく「本来集中すべき重要な仕事にリソースを割くこと」にあります。まずは1つの定常作業をAIに任せることから始め、徐々に「自分専用の自動操縦システム」を構築していくことで、エンジニアとしての生産性を一段上のステージへ引き上げることができます。 引用元: https://zenn.dev/dely_jp/articles/cf19634b63015b OpenClaw × OllamaをMacBook 16GBで動かす - ローカルLLM入門 本記事は、MacBook（メモリ16GB）という一般的な開発環境で、ローカルLLMランタイム「Ollama」とAIエージェントフレームワーク「OpenClaw」を組み合わせ、自分専用のローカルAIアシスタントを構築する手法を解説したものです。 1. 概要と構成要素 OpenClaw: TypeScript製のマルチチャネルAIエージェントフレームワークです。SlackやDiscordなど20以上のプラットフォームに対応し、Ollamaをネイティブサポートしています。単なるチャットではなく、自律的にツールを使いこなす「エージェント」としての動作に特化しています。Ollama: llama.cppをベースとしたGo製のローカルLLMランタイムです。モデルの管理（Pull/Run）が容易で、Apple Siliconの統合メモリを効率的に活用できます。推奨モデル: 日本語対応が良好で、エージェント動作に必須なツール呼び出し機能（Tool Calling）を備えた「Qwen3:8b」などが挙げられています。 2. ローカルLLM導入のメリットと課題 メリット: クラウドLLMと異なり従量課金が発生せず、実質ゼロコストで利用できます。また、データが外部サーバーに送信されないため、機密情報を扱う際のプライバシーとセキュリティが完全に確保されます。課題（制約）: パフォーマンスはハードウェアに強く依存します。16GBメモリのMacBook（CPU推論）では、8B程度のモデルでも1応答に約1分かかる場合があり、クラウドAPIと比較すると大幅なレイテンシが発生します。 3. ハイブリッド戦略の提案 実用性を高める手法として「ハイブリッド...
    Show More Show Less
    Less than 1 minute
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260330

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260330
    Mar 29 2026
    関連リンク A Small Figma Update and a Big Signal for SaaS デザインツールの最大手であるFigmaが、AIエージェント（Claude CodeやCodexなど）に対して、Figmaキャンバス上への直接的な「書き込み」権限を開放しました。これは一見小さな機能追加に見えますが、今後のソフトウェア開発とSaaS（Software as a Service）の在り方を根本から変える大きな転換点となります。 新人エンジニアの皆さんに知っておいてほしい背景として、これまでの開発プロセスでは「Figmaでデザインを作り、それをエンジニアに渡して実装する」という明確なステップがありました。しかし、今回のアップデートとMCP（Model Context Protocol）の普及により、以下のようなパラダイムシフトが起きています。 開発の起点が「AIエージェント」へ移行 現在はFigmaでワイヤーフレームを描くよりも、AIエージェント（Claude Code等）に指示を出して10パターンのプロトタイプを爆速で作る方が早くなっています。開発のスタート地点が「デザインツール」から「AIとの対話」へと移り変わっているのです。 「文脈（コンテキスト）」の集約 単一のツール（Figmaだけ、Slackだけ）が持つデータよりも、組織全体の状況（Jiraのチケット、Slackの会話、Figmaのデザイン案）を統合して理解できるAIエージェントの方が、より価値の高いアウトプットを出せるようになります。AIが情報の「集約者」となり、各SaaSはAIにデータを提供する「サプライヤー」という立ち位置に変化しつつあります。 プロセスの流動化と「受け渡し」の消失 AIの進化により、設計・デザイン・実装という各ステップの境界が消え、一つの流動的なプロセスへと統合されようとしています。これにより、従来の「デザインの納品」といった工程そのものが不要になる可能性があります。 結論として： これからのエンジニアリングでは、特定のツールを使いこなす技術以上に、「AIエージェントを司令塔として、いかに複数のツールや文脈を統合して製品を形にするか」という視点が重要になります。Figmaのような巨大なツールですら、AIエージェントという新しいインターフェースの一部になろうとしているこの変化は、エンジニアの働き方にとって非常にエキサイティングな進化と言えるでしょう。 引用元: https://metedata.substack.com/p/a-small-figma-update-and-a-big-signal AIエージェント導入で「セキュリティどうするの？」と聞かれたときの技術的な答え方 エンジニアリングの現場において、Claude CodeやCursorといった「AIエージェント」の活用は生産性を劇的に向上させる可能性を秘めています。しかし、組織への導入を検討する際、情シスやセキュリティ担当者から「AIが何をしているか見えない」「危険な操作を勝手にされないか」といった懸念を突きつけられ、導入が足踏みしてしまうケースが少なくありません。本記事は、そうした課題に対してOSS（オープンソースソフトウェア）である「AI Guardian」を活用した、技術的な裏付けのある解決策を提示しています。 AIエージェントの安全な導入を実現するために、以下の3つのアプローチが重要となります。 第一に「操作の可視化」です。AIエージェントが行うすべてのツール呼び出し（ファイルの読み書きやコマンド実行など）を自動でログに記録します。誰が、いつ、どのようなリスクのある操作を行ったかをスコアと共に可視化できるため、ブラックボックス化を防ぎ、事後の監査を容易にします。 第二に「ポリシーによる自動制御」です。YAML形式のルール設定により、AIによる破壊的な操作を未然に防ぎます。例えば、「rm -rfなどの削除コマンドをブロックする」「.envなどの機密ファイルを保護する」「git pushの前に必ず人間のレビューを挟む」といったガードレールを設けることで、AIの暴走リスクを技術的に抑え込むことが可能です。 第三に「法規制への準拠と個人情報保護」です。日本の「AI事業者ガイドライン」や各種法令（個人情報保護法など）の技術要件への対応状況を自動レポート化する機能や、プロンプトに含まれるマイナンバーや電話番号を自動検知して墨消し（マスク）する機能を備えています。 新人エンジニア...
    Show More Show Less
    Less than 1 minute
  • 私立ずんだもん女学園放送部 podcast 20260327

    私立ずんだもん女学園放送部 podcast 20260327
    Mar 26 2026
    youtube版(スライド付き) 関連リンク OpenClaw-RLで学ぶAgentic RLの報酬設計 本記事は、AIエージェントが自ら学習し進化する「Self-Evolving Agent」を実現するための手法、Agentic RL（エージェント型強化学習）と、その具体的な報酬設計について解説しています。LayerXのエンジニアブログによるもので、特に「対話するだけでモデルが賢くなる」仕組みを目指すプロジェクト「OpenClaw-RL」に焦点を当てています。 背景：なぜAgentic RLが注目されているのか AIエージェントの性能向上には、プロンプトに指示を追加する「コンテキストの活用」が一般的ですが、これには「コンテキストの肥大化」という課題があります。一方、モデル自体を更新する「Fine Tuning」はコストが高いのが実情です。Agentic RLは、強化学習の枠組みを用いて、エージェントが環境との試行錯誤を通じてモデルパラメータを継続的に最適化するアプローチとして期待されています。 OpenClaw-RLが解決する課題 通常の強化学習では、数学やコーディングのように「正解が明確なタスク」が扱われやすいですが、ユーザーとの対話ログには明確な正解ルールがありません。OpenClaw-RLでは、実際の対話ログからどのように学習信号（報酬）を取り出すか、以下の2つの手法を提案しています。 Binary報酬（二値評価） エージェントの行動に対するユーザーの反応やエラー情報を、評価用LLMに渡してスコアリングさせます。1回の評価では不安定なため、多数決（アンサンブル）をとることで報酬の信頼性を高めています。蒸留報酬（コンテキスト蒸留） 「観測情報をコンテキストに含めた教師モデル」と「含めていない生徒モデル」を比較し、生徒の出力を教師に近づける手法です。これにより、外部からのフィードバックをモデルの内部知識として効率よく取り込むことができます。 エンジニアとしての注目ポイント 強化学習で主流の「GRPO」アルゴリズムは、1つのプロンプトに対して複数の試行（rollout）を必要としますが、実際の対話では1つの行動に1つの反応しか得られないため、そのまま適用できないという技術的課題があります。OpenClaw-RLではこれを相対評価値として扱う工夫をしていますが、まだ改善の余地がある興味深い領域です。 新人エンジニアの方にとっても、「使えば使うほどAIがパーソナライズされ賢くなる」という未来を支える、非常にエキサイティングな技術トピックと言えます。 引用元: https://tech.layerx.co.jp/entry/openclawrl-agenticrl How Middleware Lets You Customize Your Agent Harness AIエージェント開発における新しい設計パターンである「エージェント・ミドルウェア」について解説された記事です。LangChainなどのフレームワークを使ってエージェントを構築する際、エンジニアが直面する「細かな制御の難しさ」を解決するための強力な手法が紹介されています。 1. エージェント・ハーネスとミドルウェア まず「エージェント・ハーネス（Agent Harness）」とは、LLMを外部環境やツール、メモリと接続し、ループ実行させるためのシステム基盤を指します。通常、このループの内部ロジックをカスタマイズするのは困難ですが、Web開発でおなじみの「ミドルウェア」の考え方を導入することで、ループの各ステップに独自の処理を差し込むことが可能になります。 2. 6つの主要なフック（介入ポイント） ミドルウェアを利用すると、以下のタイミングでカスタムロジックを実行できます。 before_agent / after_agent: エージェントの開始時と終了時に実行。リソースの初期化や結果の保存に最適です。before_model / after_model: モデル呼び出しの前後で実行。個人情報（PII）の削除や、人間による確認（Human-in-the-loop）を挟むのに適しています。wrap_model_call / wrap_tool_call: モデルやツールの実行自体を包み込みます。リトライ処理やキャッシュ、動的なツールの切り替えなどに利用されます。 3. 具体的な活用シーン 新人エンジニアにとってもイメージしやすい、実戦的な例がいくつか挙げられています。 コンプライアンスとセキュリティ: プロンプトだけで個人情報の流出を防ぐのは不確実です。ミドルウェアで機械的に検知・マスクすることで、確実...
    Show More Show Less
    Less than 1 minute