Agent

【2026年最新】世界一わかりやすい Agent Skills 完全ガイド — まとめ 元記事: 【2026年最新】世界一わかりやすいAgent Skills完全ガイド（株式会社AIworker） 紹介ポスト: Fujin(@fujin_metaverse) Agent Skills とは？ 一言で言うと、「AIエージェントに渡す新人研修マニュアル」。 会社の新入社員にマニュアルを渡すのと同じ要領で、SKILL.md というテキストファイルに「やり方」を書いて所定のフォルダに置くだけ。AIエージェントが自動的にそれを見つけて読み込み、指示通りに仕事をしてくれる。 2025年12月に Anthropic がオープンスタンダードとして公開 Claude, GitHub Copilot, OpenAI Codex, Cursor など主要AIツールが対応 2026年2月時点でマーケットプレイス登録数は20万件超 なぜ Agent Skills が必要か — プロンプトの3つの限界 従来のプロンプト運用には以下の限界があった。Agent Skills はこれらを全て解決する。 限界 問題 Agent Skills での解決 毎回同じ説明が必要 技術スタック、規約、コミットルールを毎回ゼロから伝える 一度書けば繰り返し使える チーム共有できない 優れたプロンプトがチャット履歴に埋もれる Git で管理・共有可能 コンテキスト圧迫 毎回全情報を読み込むと、肝心のタスクの余裕が減る 必要な時に必要な分だけ読み込む「段階的開示」 Claude Code のセットアップ手順 Agent Skills を使う最も一般的な環境は Claude Code（Anthropic 提供のターミナル型AIコーディングツール）。ブラウザ版の Claude.ai と違い、PCのファイルを直接読み書きできるのが特徴。 1 2 3 4 5 6 7 8 9 10 11 12 # 1. Node.js の確認（v18.0.0 以上が必要） node --version # 2. Claude Code のインストール（Mac / Linux） curl -fsSL claude.ai/install.sh | bash # 3. 確認 claude --version # 4. 初回起動（ブラウザでログイン画面が開く） mkdir ~/my-project && cd ~/my-project claude SKILL.md の書き方 SKILL.md は YAMLフロントマター + Markdown 本文 の2部構成。 ...

Anthropic 社内チームの Claude Code 活用 — マーケから法務まで、全部門が「自分で自動化」する時代 Anthropic 公式記事: How Anthropic teams use Claude Code 再現記事: Claude Code で広告バナー200本を15分で作る手順 紹介ポスト: commte はじめに Anthropic が「自社のチームが Claude Code をどう使っているか」を公式ブログで公開した。注目すべきは、エンジニアリングチームだけでなく、マーケティング、法務、データサイエンス、デザインといった非技術部門が、コードを1行も書かずに高度な自動化を実現している点。 特にマーケティングチームの事例は、ツイートでも「えぐい広告手法」として話題になり、実際に再現して15分で広告バナー200本を生成した記事も登場した。 マーケティングチーム — たった1人で10倍の成果 チーム構成 驚くべきことに、Anthropic のグロースマーケティングチームはエンジニアがゼロの1人チーム。担当の Austin Rau 氏は、元々ターミナルの開き方すら知らなかったという。 それが、非技術者向けガイドを見てから1週間で、Figma プラグインと広告コピー生成ワークフローの両方を構築した。 4つの自動化事例 1. Google Ads の広告コピー生成（2時間 → 15分） 数百件の既存広告 CSV を Claude Code に読み込ませ、パフォーマンスの低い広告を自動特定。改善案をサブエージェント方式で生成する。 サブエージェント設計のポイント: エージェント 専門 制約 headline-writer 見出し生成 30文字以内 description-writer 説明文生成 90文字以内 1つのプロンプトで全部やらせるのではなく、タスクごとに専門エージェントを分けることで、文字数制約を守りつつ品質を維持する。 2. Figma プラグインでバナー一括生成（数時間 → 0.5秒） Claude Code で自作した Figma プラグインが、テンプレートのテキストノードを CSV データで自動差し替え。最大100パターンのバナーを一括生成する。 ...

Claude Code の能力を10倍にする CLAUDE.md — AI エージェントのマネジメント哲学 紹介ポスト: チャエン @masahirochaen 解説記事: Zenn: Claude Codeの能力を10倍にする CLAUDE.md の中身を見てみた はじめに 海外で大バズりした「Claude Code の能力を10倍にする CLAUDE.md」。Anthropic の Claude Code 開発者が実際に使っているベストプラクティスを、1つの CLAUDE.md ファイルに構造化したもの。 これは単なるプロンプトテンプレートではない。AI エージェントをどうマネジメントするかという哲学を、実装可能な形にまとめたファイルだ。 6つのワークフロー原則 1. Plan Mode デフォルト 「3ステップ以上、またはアーキテクチャ判断を伴うタスクは、必ず Plan Mode から始めよ」 Claude Code が実装に飛びつくのを防ぐ最も重要なルール。計画なしに実装を始めると、途中で方向修正が必要になったとき、修正の連鎖（カスケード失敗）が発生する。 やり方: Shift+Tab を2回押して Plan Mode に入る Claude の計画が納得できるまでやり取りを繰り返す 計画が固まったら Auto-Accept モードに切り替えて一気に実装 実行中に問題が起きたら: すぐに Plan Mode に戻って再計画する Plan Mode は「最初の設計」だけでなく「リカバリー」にも使う 2. サブエージェント戦略 「リサーチ、探索、並列分析はサブエージェントに委譲せよ」 メインのコンテキストウィンドウは有限のリソース。調査や分析をメインエージェントにやらせると、コンテキストが汚れて本来のタスクの品質が下がる。 サブエージェントに委譲すべきタスク: コードベースの調査・探索 複数ファイルの並列分析 計算集約的な処理 独立した検証作業 メインエージェントに残すべきタスク: 最終的な設計判断 コードの実装 統合・結合 初心者向け解説: 「サブエージェント（Task）」とは何か 「サブエージェント」と聞くと難しそうだが、仕組みはシンプル。Claude Code が内部的に「別の Claude」を立ち上げて、作業を分担する機能のこと。Claude Code ではこれを Task と呼ぶ。 ...

git-lrc — コミット時に AI が無料でコードレビューしてくれるツール リポジトリ: HexmosTech/git-lrc 紹介ポスト: commte これは何か git-lrc は、git commit のタイミングで自動的に AI コードレビューが走るツール。Git フックとして動作し、コミット前の差分を AI（Google Gemini）に分析させ、バグやセキュリティ問題をブラウザ上の UI でインラインコメントとして表示してくれる。 しかも Gemini の無料枠を使うので完全無料。 なぜこれが作られたのか AI エージェント時代の新しい問題 Claude Code や Cursor などの AI コーディングエージェントは、コードを高速に生成する。しかし同時に、黙ってロジックを削除したり、挙動を変えたり、バグを混入させることもある — しかもユーザーに何も言わずに。 問題に気づくのは、たいてい本番環境にデプロイした後。 既存のコードレビューの限界 PR レビュー: チームメンバーの時間を消費する。AI 生成コードの量が増えるとレビューが追いつかない 手動チェック: 大量の差分を毎回目視確認するのは非現実的 CI/CD のテスト: テストがカバーしていない箇所の論理変更は検出できない git-lrc のアプローチ 「コミット」という全開発者が必ず通るポイントにフックすることで、レビュー漏れをほぼゼロにする。エディタや AI ツールキットが何であっても、Git は共通基盤。コミットは必須操作なので、スタックに関係なくレビューが走る。 どう動くのか セットアップ（約1分、1回だけ） 1 2 3 4 5 # インストール（Mac / Linux） curl -fsSL https://hexmos.com/lrc-install.sh | sudo bash # 初期設定（ブラウザで API キーを取得） git lrc setup 必要なのは2つ: ...

コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い 紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」 はじめに 2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した: 「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」 AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。 プロンプトエンジニアリング vs コンテキストエンジニアリング 観点 プロンプトエンジニアリング コンテキストエンジニアリング スコープ 1つの入力テキストの書き方 モデルが見る情報の全体設計 焦点 指示の言い回し・構造 情報の選択・順序・形式・量 対象 単発の質疑応答 複雑な推論、マルチターン、エージェント 複雑さ 文章レベル システムレベルのパイプライン 例え 「質問の仕方を工夫する」 「解答に必要な教科書・資料・道具を揃える」 プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。 なぜプロンプトだけでは不十分なのか よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。 原因はプロンプトでも検索でもなく、コンテキストの構造にある。 プロンプトの 3 つの限界 情報不足: 質問は完璧でも、判断に必要な背景情報が足りない 情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる） 情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる コンテキストエンジニアリングは、この 3 つを体系的に解決する。 コンテキストエンジニアリングの 4 つの柱 1. 構成（Composition）— 何を渡すか タスクに必要な「材料」を選択する: ...

三菱UFJ銀行におけるエンタープライズAI駆動開発のリアル 三菱UFJインフォメーションテクノロジー（MUIT）R&D部 尾根田倫太郎氏の講演まとめ 出典: SpeakerDeck エンタープライズAI駆動開発とは AI駆動開発とは、AIコーディングエージェントを前提とした開発方式のこと。従来の人海戦術的な開発と異なり、自然言語での指示により複数のソースコードが短時間で自動生成される。 三菱UFJ銀行（MUFG）では、この手法を金融システムの内製開発に適用する取り組みを進めている。 エンタープライズ特有の条件 一般的なAI駆動開発と異なり、銀行システムには以下の制約がある。 数十万〜数百万行規模のシステム 数十〜数百人規模のチーム Excel方眼紙での設計書作成が標準 インターネット非接続環境での開発 主要ツールとして Cline または Claude Code を採用している。 Agent Skills — AIへの「教科書」 Agent Skills は、AIコーディングエージェントに教科書として機能するマークダウンファイルとして定義されている。2025年12月に Agentic AI Foundation により標準規格化された。 従来は「人への教育」が中心だったが、今後はAIエージェントへの教育へシフトするという発想の転換が示された。 Agent Skills とは何か Agent Skills は、AIエージェントに新しい能力や専門知識を与えるための、フォルダ単位でパッケージ化された手順書・スクリプト・リソースの集合体である。エージェントが必要に応じてスキルを発見・読み込み、タスクをより正確かつ効率的にこなせるようにする仕組み。 公式サイト: agentskills.io なぜ Agent Skills が必要か AIエージェントは汎用的な能力は高いが、特定の企業・チーム・ドメイン固有のコンテキストを持っていない。Agent Skills はこのギャップを埋める。 対象 メリット スキル作成者 一度作れば複数のエージェント製品で横断的に利用可能 エージェント開発者 Skills 対応するだけでエンドユーザーが機能拡張できる 企業・チーム 組織の知識をバージョン管理可能なパッケージとして蓄積 SKILL.md の基本構造 Agent Skills の実体は、SKILL.md というマークダウンファイルを含むフォルダ。YAMLフロントマターでメタデータを定義し、本文に手順を記述する。 skill-name/ ├── SKILL.md # 必須: メタデータ + 手順 ├── scripts/ # 任意: 実行可能スクリプト ├── references/ # 任意: 補足ドキュメント └── assets/ # 任意: テンプレート、画像等 SKILL.md の例: ...

Agent Plugins for AWS — AI コーディングエージェントに AWS の専門知識を装着する 紹介ポスト: moritalous 公式ブログ: Introducing Agent Plugins for AWS | AWS Developer Tools Blog リポジトリ: awslabs/agent-plugins はじめに 2026年2月、AWS は Agent Plugins for AWS をオープンソースで公開した。Claude Code や Cursor といった AI コーディングエージェントに AWS の専門知識を「スキル」として装着するプラグインライブラリである。 これは単なる CLI ラッパーではない。AI エージェントがアーキテクチャ設計 → コスト見積もり → IaC 生成 → デプロイまでを一貫して実行できる「AWS ドメイン能力層」を追加するもの。 従来: 開発者が AWS ドキュメントを読み → 設計を考え → CDK/CFn を書き → デプロイ 今後: 「deploy to AWS」と言うだけ → AI が全工程を実行（人間は確認・承認のみ） Agent Plugin とは何か プラグインの構成要素 Agent Plugin は4つの部品を1つのパッケージにまとめたもの。 ...

cmux — AIコーディングエージェント時代のターミナル cmux とは？ cmux は、AIコーディングエージェントとの並行作業に最適化された macOS ネイティブのターミナルアプリ です。Ghostty の描画エンジン (libghostty) をベースに、Swift + AppKit でゼロから構築されています。 Electron ではなくネイティブ実装なので、起動は高速、メモリ消費も少なく、GPU アクセラレーションによる滑らかな描画が特徴です。 “The terminal built for AI coding agents” 公式サイト: https://cmux.dev GitHub: https://github.com/manaflow-ai/cmux (AGPL-3.0) なぜ cmux が必要なのか？ Claude Code、Codex、Gemini CLI、Aider、Goose など、ターミナルベースの AI エージェントを日常的に使う開発者が増えています。しかし従来のターミナルや tmux では、複数のエージェントセッションを並行管理するのが大変でした。 「どのタブでどのエージェントが動いてるか分からない」 「エージェントが質問してるのに気づかなかった」 「開発サーバーの確認のためにブラウザとターミナルを行き来するのが面倒」 cmux はこれらの課題を解決するために設計されています。 主な機能 1. 縦タブ（バーティカルタブ）でワークスペースを一覧管理 左サイドバーに縦並びのタブが表示され、各ワークスペースの状態が一目で分かります： Git ブランチ名 リンク済み PR のステータスと番号 作業ディレクトリ リッスン中のポート番号 最新の通知テキスト Firefox の縦タブに馴染みがある方なら、その便利さは想像がつくはず。タスクごとにワークスペースを作り、Cmd+1〜8 で瞬時に切り替えられます。 2. 通知リング — エージェントが注意を求めたら光る AIエージェントが応答を待っている時、ペインに 青い通知リング が表示されます。サイドバーのタブにも未読バッジが付くので、複数エージェントを走らせていても「見逃し」がありません。 Cmd+Shift+U で最新の未読通知にジャンプ Cmd+I で通知パネルを開いて一覧確認 OSC 9/99/777 エスケープシーケンスを自動検知 CLI からも送信可能: cmux notify --title "完了" --body "ビルド成功" 3. インアプリブラウザ — ターミナルの横にブラウザを並べる WebKit ベースのブラウザがアプリ内に統合されています。ターミナルペインの隣にブラウザを分割表示して、開発サーバーのプレビューや PR の確認がワンストップで完結します。 ...

業務フローの設計にPowerPointではなくBPMNを使うべき理由 — Claude Code時代の詳細設計 はじめに 業務システムの設計でSwim Lane（スイムレーン）形式の業務フローを書くとき、多くの現場ではPowerPointやFigmaが使われています。見た目は整えやすく、関係者への説明資料としてはよくできています。 しかし、この「人間が読むための図」を設計の源泉にしてしまうと、あと工程で大きなコストが発生します。特に、Claude CodeのようなAIエージェントを開発に活用する場合、設計成果物のフォーマット選択が開発効率を決定的に左右します。 本記事では、実際にPowerPointのスライドからBPMN 2.0に変換した経験をもとに、BPMNを採用する利点を解説します。 PowerPointの業務フローが抱える問題 PowerPointのスライドに描かれた業務フローは、本質的に「画像」です。 PowerPoint (.pptx) ├── 図形の座標とスタイル情報 ├── テキストボックスの文字列 └── グループ化とレイヤー これは人間が見るには十分ですが、次のような問題があります。 構造情報がない: 「この矢印がどのタスクからどのタスクへ向かっているか」をプログラムが読み取れない アクターの定義が曖昧: レーンの境界が図形の配置で表現されているだけで、意味的な紐付けがない 分岐条件が自然言語: ゲートウェイの条件が図中のテキストに埋め込まれ、機械的に検証できない フロー間の接続が不明確: 複数スライドにまたがるフローの接続点（「次のフローへ」）が視覚的な慣習に依存 BPMN 2.0とは BPMN（Business Process Model and Notation） は、業務プロセスを図式化するための国際標準記法です。OMG（Object Management Group）が策定し、ISO 19510として国際標準化されています。現行バージョンはBPMN 2.0.2です。 BPMNの最大の特徴は、人間が理解できるフロー図と機械が処理できるXMLが一つのファイルに同居している点です。プールとレーン（Swim Lane）でアクターを表現し、タスク・ゲートウェイ・イベントでプロセスの流れを記述します。 BPMN 2.0がもたらす構造化 BPMN 2.0はXML形式で、見た目と意味の両方を持つフォーマットです。 1 2 3 4 5 6 7 8 9 10 11 12 13 <bpmn:process id="Process_1" isExecutable="false"> <bpmn:laneSet id="LaneSet_1"> <bpmn:lane id="Lane_reception" name="太平受付担当"> <bpmn:flowNodeRef>r1</bpmn:flowNodeRef> <bpmn:flowNodeRef>r2</bpmn:flowNodeRef> </bpmn:lane> <bpmn:lane id="Lane_system" name="システム" /> </bpmn:laneSet> <bpmn:task id="r1" name="修理内容の特定" /> <bpmn:exclusiveGateway id="d2" name="保証範囲?" /> <bpmn:sequenceFlow sourceRef="r1" targetRef="d2" /> </bpmn:process> この構造から、以下がプログラム的に読み取れます。 ...

Snowflake: Snowpark Snowpark とは何か？ Snowpark for Python ができること、できないこと Snowflake の新機能 “Snowpark” Deep Dive！仕組みを覗いてみた！ Apache Spark 今さら聞けない Python - Spark のご紹介