AI/LLM

三菱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つのパッケージにまとめたもの。 ...

AI は会話が長くなるほど「迷子」になる — Microsoft × Salesforce の衝撃の研究 紹介ポスト: kosuke_agos 論文: LLMs Get Lost In Multi-Turn Conversation Microsoft Research: 公式ページ はじめに 「AI と長く会話するほど、AI の知能が劣化する」— これは体感ではなく、Microsoft Research と Salesforce Research が 20万件以上の AI 会話を分析 して科学的に証明した事実である。 論文タイトルは “LLMs Get Lost In Multi-Turn Conversation”（LLM はマルチターン会話で迷子になる）。GPT-4.1、Claude 3.7 Sonnet、Gemini 2.5 Pro を含む 15 モデル全てで、会話が長くなるほど性能が劇的に低下することが明らかになった。 衝撃の数字 指標 数値 平均性能低下 39% 不安定性（unreliability）の増大 +112% 精度の変化 90% → 約 51% テストしたモデル数 15（大小問わず全て劣化） 最も重要な発見: 高性能モデルも小型モデルも、同じように劣化する。 Claude 3.7 Sonnet、Gemini 2.5 Pro、GPT-4.1 といったトップモデルでも 30〜40% の性能低下が観測された。モデルの「賢さ」では回避できない、構造的な問題であることが判明した。 研究チームと手法 著者 名前 所属 Philippe Laban Microsoft Research Hiroaki Hayashi Salesforce Research Yingbo Zhou Salesforce Research Jennifer Neville Microsoft Research テスト対象モデル（15種） OpenAI: GPT-4o-mini, GPT-4o, o3, GPT-4.1 Anthropic: Claude 3 Haiku, Claude 3.7 Sonnet Google: Gemini 2.5 Flash, Gemini 2.5 Pro Meta: Llama 3.1-8B, Llama 3.3-70B, Llama 4 Scout その他: Microsoft Phi-4, AI2 OLMo-2-13B, Deepseek-R1, Cohere Command-A Sharding（シャーディング）— 現実の会話を再現する手法 ユーザーは通常、最初から完璧な指示を出さない。 ...

Claude Code に重大な脆弱性 — 「リポジトリを開くだけ」で任意コード実行の恐れ セキュリティ企業 Check Point が、Anthropic の AI コーディング支援ツール Claude Code に複数の重大な脆弱性を発見したと報告しました。細工されたリポジトリを開くだけで不正なコマンドが実行される恐れがあり、AI 開発ツールの信頼モデルに一石を投じる内容です。 何が起きたのか Claude Code には Hooks（ツール実行前後にシェルコマンドを自動実行する仕組み）、MCP サーバー（外部ツール連携）、環境変数の読み込みといった設定機構があります。これらが悪用されることで、未信頼のディレクトリで Claude Code を起動した際に、任意のシェルコマンド実行や Anthropic API キーの流出が可能となることが判明しました。 つまり、攻撃者が悪意ある設定ファイルを仕込んだ Git リポジトリを用意し、開発者がそれを git clone して Claude Code を起動するだけで攻撃が成立します。 報告された脆弱性 CVE-2025-59536（CVSS 8.7 / High）— コードインジェクション ツールの初期化時に自動実行を許すコードインジェクションの脆弱性です。Hooks や MCP サーバーの設定を悪用し、Claude Code が起動した瞬間に攻撃者のコマンドが実行されます。リモートコード実行（RCE）に直結する、最も深刻な問題です。 CVE-2026-21852（CVSS 5.3 / Medium）— 情報漏えい プロジェクト読み込み時に環境変数の値が外部に漏洩する可能性がある脆弱性です。Anthropic API キーなどの機密情報が窃取されると、攻撃者がそのアカウントで API を不正利用できてしまいます。 その他の脆弱性 上記 2 件以外にも、同等の深刻度を持つ欠陥が確認されています。 なぜ危険なのか — 設定ファイルが攻撃経路になる 従来のセキュリティモデルでは「コードを実行しなければ安全」という前提がありました。しかし今回の脆弱性では、設定ファイル自体が攻撃経路となります。 設定機構 通常の用途 悪用方法 Hooks ツール実行前後にシェルコマンドを自動実行 悪意あるコマンドを起動時に自動実行 MCP サーバー 外部ツールとの連携設定 偽サーバーを指定しデータを外部送信 環境変数 API キーなどの機密情報管理 設定ファイル経由で値を外部に流出 開発者が日常的に行う「リポジトリを clone して開発環境を立ち上げる」という行為自体がリスクになるという点で、VS Code の .vscode/ 設定を悪用する攻撃と同種のパターンです。ただし AI ツールはファイルシステムへの広範なアクセス権とシェルコマンドの実行権を持つため、影響はより深刻になりえます。 ...

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 の確認がワンストップで完結します。 ...

Vibe Coding 2.0 — 「何を作らないか」を知る 18 のルール Vibe Coding とは（前提知識） Vibe Coding は、Andrej Karpathy（OpenAI 共同創設者）が 2025 年初頭に提唱した概念で、「コードの細部を手で書く」のではなく、AI に自然言語で指示してコードを生成させ、“ノリ（vibe）“で開発を進める スタイルを指します。Cursor や Claude Code などの AI コーディングツールの普及とともに広まりました。 MVP とは MVP（Minimum Viable Product / 実用最小限の製品） とは、顧客に価値を提供できる最小限の機能だけを備えた製品のことです。完璧な製品を作り込んでからリリースするのではなく、核となる機能だけを素早く形にして市場に投入し、実際のユーザーからフィードバックを得ながら改善していくアプローチを指します。 目的: アイデアが市場に受け入れられるかを、最小のコストと時間で検証する 考え方: 「完成品」ではなく「検証のための道具」。100 点を目指すのではなく、60 点で出して学ぶ 例: 動画配信サービスなら、レコメンド機能や検索機能を後回しにして、まず「動画を再生できる」だけのアプリをリリースする Vibe Coding 2.0 の文脈では、AI ツールを活用して MVP を高速にシップ（出荷）する ことが繰り返し強調されています。以下のルール群は、すべて「いかに早く MVP を世に出すか」を軸に設計されています。 Vibe Coding 2.0 とは Harshil Tomar 氏が X で投稿 した 「Vibe Coding 2.0: 18 Rules to be the Top 1% builder」 は、Vibe Coding の「次のフェーズ」を定義したものです。 ...

コードレビューは CLAUDE.md / skills に書け — 同じ指摘を繰り返すな 基本情報 発表者: 戸塚翔太（Tech Lead / EM、スタートアップ開発責任者） イベント: 「一歩踏み込む Claude Code 活用 LT 会」（Findy 主催、2026年2月22日） スライド: Speaker Deck 問題提起 「人間に対してレビューするの、もうやめませんか？」 コードレビューにおいて以下のような無駄が繰り返されている: 問題 具体例 同じ指摘の繰り返し 変数名の命名規則、コーディングスタイルへの指摘が毎回発生 修正ラリー 「指摘修正しました」→ 再レビュー → 再指摘 の往復 アーキテクチャ的な問題 根本的な設計の問題が PR 段階で発覚する これらはレビュアーの時間を奪い、開発速度のボトルネックになっている。 解決策: 使い捨てコメントをナレッジに変える 核心のアイデアは 「レビューで出た指摘を、PR のコメントとして消費するのではなく、CLAUDE.md や skills に書き込んでナレッジとして蓄積する」 こと。 従来: レビュー指摘 → PR コメント → 修正 → 忘れられる → また同じ指摘 提案: レビュー指摘 → CLAUDE.md / skills に追記 → 以降 Claude が自動で遵守 CLAUDE.md に書くもの コーディング規約（命名規則、ディレクトリ構成） アーキテクチャ上のルール（「この層でこの処理はしない」等） プロジェクト固有のパターン skills に書くもの レビュー観点をスキルとして定義 Claude Code が PR 作成前にセルフチェックできるようにする 自動化の仕組み 2 つの適用方法が紹介されている: ...

name: tmux-focus description: “tmux ウィンドウの Issue/PR 切替: /tmux-focus [-w|-r] ” tmux-focus スキル 現在の tmux ウィンドウの Issue/PR を切り替えるスキル。 使い方 /tmux-focus <number> — Issue モード Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh <number> ウィンドウ名を issue-<number> に変更し、対応する GitHub Issue をブラウザで開く。 /tmux-focus -w <number> — PR worktree モード gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。 Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number> ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。 EnterWorktree ツールで worktree を作成する。 worktree 内で以下を実行: 1 gh pr checkout <number> /tmux-focus -r <number> — PR レビューモード gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。 Bash で以下を実行: 1 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number> ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。 worktree 内でなければ EnterWorktree ツールで worktree を作成する。 worktree 内で以下を実行: 1 gh pr checkout <number> PR のコード差分をレビュー開始する（gh pr diff <number> で差分を取得し、変更内容を分析）。 スクリプトが存在しない場合 ~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh が存在しない場合は、以下の内容で作成して chmod +x する。 ...

業務フローの設計に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> この構造から、以下がプログラム的に読み取れます。 ...

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する 背景 本番環境の ECS コンテナで発生したエラーは、CloudWatch Logs → Lambda → GitHub Issue という流れで自動起票される仕組みを運用しています。 タイトルは [prod][myapp] errors detected、ラベルは CloudWatchLog で統一されており、1つの Issue に複数のエラーブロックがまとまって届きます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ## Error Report - 2026-02-12 01:32:28 UTC - **Environment**: prod - **Log Group**: `/ecs/myapp-prod-ecs` - **Error Blocks**: 3 ### [1] 2026-02-12 01:32:26 UTC - `application` （スタックトレース） ### [2] 2026-02-12 01:45:10 UTC - `application` （スタックトレース） ### [3] 2026-02-12 02:01:33 UTC - `application` （スタックトレース） この Issue をそのまま放置すると、異なるエラーが混在したまま溜まっていきます。手作業で分類・個別 Issue 化するのは地味に面倒で、後回しにしがちでした。 ...