youtube版(スライド付き) 関連リンク skill-creatorから学ぶSkill設計と、Orchestration Skillの作り方本記事は、Anthropicが提唱する「Agent Skills（エージェント・スキル）」の設計思想と、そのベストプラクティスを解説したドキュメントです。特に、スキル作成を支援するメタスキル「skill-creator」の構造を分析し、複雑なタスクをこなす「オーケストレーション型スキル」の作り方を、新人エンジニアにも分かりやすく提示しています。 1. Agent Skillsの基本と「段階的開示」 Agent Skillsとは、AIエージェントに特定のワークフローや知識を教える命令セットです。設計の核心は「Progressive Disclosure（段階的開示）」にあります。 AIの記憶領域（コンテキストウィンドウ）は限られた「公共財」であるため、最初から全ての情報を読み込ませるのではなく、必要に応じて3段階で情報をロードします。 Level 1: スキル名と説明（常に読み込む。トリガー判定用） Level 2: メインの指示（スキル発動時に読み込む） Level 3: スクリプトや参照資料（実行時に必要になったら読み込む） 2. 失敗しないスキル設計の7つのベストプラクティス「skill-creator」の構造から、以下の汎用的な設計パターンが学べます。指示の委譲: メインの指示書（SKILL.md）は司令塔に徹し、専門的な処理はサブエージェントに任せる。スクリプトの活用: ループや計算、ファイル操作など、AIが苦手な「確定的処理」はプログラム（Python等）に外出しする。スキーマ契約: AIとプログラムの間でやり取りするJSON形式を厳密に定義し、連携ミスを防ぐ。 Why-driven設計: 「絶対〜しろ」と命令するだけでなく「なぜそれが必要か（理由）」を説明することで、AIの柔軟な対応を引き出す。 Description（説明文）の最適化: 説明文が悪いとスキルが起動すらしないため、トリガー条件を具体的に記述する。チャット外での連携: 大量のデータ評価など、チャットUIでは難しい作業は専用のHTMLビューアなどを生成して行う。移植性の確保: 実行環境の制約（並列処理ができるか等）に応じて、自動で処理を切り替える工夫をする。 3. 2つのオーケストレーション戦略複雑な処理をまとめる際、記事では2つのアプローチを比較しています。 Sub-agent型: 1つの親スキルが、複数の「子のAI」を生成して並列で動かす。評価や分析を同時に行いたい場合に有効。 Skill Chain型: 独立した小さなスキルを「数珠繋ぎ」にしてパイプラインを作る。調査、実行、レポート作成など、手順が直列で決まっている場合に適している。結論これからのスキル開発は、単なる「プロンプトの束」ではなく、制御フロー、専門ロジック、データ契約、UIを持つ「小さなソフトウェア」として設計することが求められます。この構造化を意識することで、より信頼性が高く、メンテナンスしやすいAIエージェントを構築できるようになります。引用元: https://nyosegawa.github.io/posts/skill-creator-and-orchestration-skill/ MCPはなぜCLIに負けたのか —— 経緯と構造を整理する 2024年にAnthropicが発表したMCP（Model Context Protocol）は、当初「AIとツールの架け橋」として業界を席巻しましたが、2026年現在ではCLI（コマンドラインインターフェース）に対してその優位性を失いつつあります。本記事は、なぜMCPが短期間でCLIに追い抜かれたのか、その構造的な背景を分析しています。【MCP誕生の背景：モデルの「能力不足」】 2024年11月時点のAIモデルは、ツールの入出力を自力で解釈する能力が不安定でした。そのため、MCPはモデルとツールの間にJSON-RPCベースの仲介層を置き、構造化されたデータ（スキーマ）で「何ができるか」を明示的に教える「補助輪」としての役割を果たしました。【モデルの進化が前提を壊した】 2025年以降、推論能力が飛躍的に向上した新世代モデル（Opus 4.6等）が登場しました。これらのモデルは、manページやヘルプテキストを読むだけで適切なコマンドを組み立て、エラーが発生しても自律的に修正できる能力を獲得しました。結果として、モデル側の進化が「構造化された仲介層」というMCPの必要性を解消してしまいました。【トークン効率と運用コストの壁】実運用におけるCLIとの比較では、以下の深刻な課題が浮き彫りになりました。トークン効率の悪さ: MCPはツール定義だけで数万トークンを消費し、コンテキストウィンドウを圧迫します。一方、CLIはモデルが既知の知識（Bash等）を利用できるため、数百トークンの指示（README等）で済み、40倍以上の効率差が出るケースもあります。認証と権限管理: CLIは既存の認証基盤（SSOやkubeconfig）をそのまま流用でき、コマンド単位での細かな権限制御も容易です。対してMCPは独自の認証レイヤーやプロセス管理が必要で、導入・運用の摩擦が大きいという欠点があります。【開発者が得られる教訓】 MCPを設計したAnthropic自身も、現在はMCPのスケーリング問題を認め、ツール定義を動的に検索する手法やコード実行による回避策を提案しています。ここから得られる重要な教訓は、「現在のモデルの能力不足を補うための技術は、その規格化が完了する前に、モデル自身の進化によって追い越されるリスクがある」ということです。エンジニアがエージェントのアーキテクチャを選定する際は、特定のプロトコルに固執せず、モデルの進化スピードを見据えた柔軟な設計が求められます。引用元: https://zenn.dev/hiraly/articles/3409b886607274 Ruby で作る Coding Agent 本書は、PythonやNode.jsでの実装例が多い「Coding Agent（コーディング・エージェント）」を、あえて著者の愛好するRubyを用いてゼロから自作する過程を解説した、新人エンジニアにも非常に分かりやすい実践ガイドです。AIエージェントがどのような仕組みで動き、どのように「道具（ツール）」を使いこなすのか、そのエッセンスが段階を追って説明されています。主な内容は以下の4つのステップに集約されます。 1. 基本的な対話と履歴の保持最初に、Gemini APIを用いてユーザーの入力をモデルに送り、レスポンスを表示する無限ループを作成します。しかし、単なる一問一答では文脈（コンテキスト）が維持されないため、会話内容を配列（@history）に保持し、過去のやり取りを毎回モデルに送信する仕組みを導入します。これにより、以前の発言を踏まえた会話が可能になります。 2. 「ツール（Function Calling）」の実装コーディング・エージェントの本質は、AIが自らファイルを読み書きしたり、コマンドを実行したりすることにあります。本書では、Google Geminiの「Function Calling」という仕組みを利用しています。定義: read_file や write_file といった機能の名称と引数の型をJSON形式で定義し、モデルに伝えます。実行: モデルが「このツールを使いたい」と返してきた場合、プログラム側で実際の処理（ファイルの読み込み等）を行い、その結果を再度モデルに返します。これにより、AIが「ソースコードを読んで内容を把握する」といった行動が可能になります。 3. 汎用性の向上：コマンド実行ツールの追加特定のファイル操作だけでなく、ls や grep といった任意のUNIXコマンドを実行できる exec_command ツールを実装することで、エージェントの柔軟性を飛躍的に高めています。これにより、エージェントは自らプロジェクト構造を把握し、テストを実行するといった複雑なタスクもこなせるようになります。 4. トークン制限への対策（履歴の圧縮）会話が長くなると、モデルに送るトークン数（文字数制限のようなもの）が上限に達してしまいます。これを防ぐため、一定量を超えた場合に「古い会話を要約して圧縮する」ロジックを導入しています。ここで重要なのは、ツール実行の履歴（呼び出しと応答のペア）が途中で途切れないように分割位置を調整する工夫です。まとめ自作を通じて、AIエージェントは「プロンプト」「履歴管理」「ツール実行」の組み合わせで成り立っていることが理解できます。ライブラリが豊富なRubyを使うことで、驚くほどシンプルに強力な開発補助ツールが構築できることを示しており、AI技術の裏側を知りたい新人エンジニアにとって最高の教材となっています。引用元: https://yoshiori.hatenablog.com/entry/2026/03/04/002852 漫画家にはなったけど、まだベレー帽を被る機会がありません。子供の頃は漫画家になったら自動的にベレー帽が生えると思っていたのですが… 漫画家の岡本倫氏が綴った、夢を叶えた後の「理想と現実のギャップ」を巡るユーモラスなエピソードです。幼少期に抱いた「漫画家になれば自然とベレー帽を被る姿になる」という幻想が現実は異なり、自ら購入（行動）しない限り手に入らないことに気づく様子を軽妙に描いています。象徴的なスタイルへの憧れと自発的な一歩の大切さを教えてくれる、新人エンジニアの心も和ませるような温かみのある話題です。引用元: https://togetter.com/li/2671076 お便り投稿フォーム VOICEVOX:ずんだもん

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related