nwiizo

Claude CodeのHooksは設定したほうがいい

開発生産性を測る時に測定の落とし穴から抜け出すために

正義のエンジニアという幻想 - 媚びないことと無礼の境界線

生成AIで物語を書くためにプロンプトの制約や原則について学ぶ、という話をしてきました #女オタ生成AI部

諸君、聞かれよ。本日、私は「女オタ生成AIハッカソン2025夏東京」なる前代未聞の催しにて、生まれて初めて登壇することと相成った。かつての私は純朴なプログラマーであり、「変数名を30分悩んだ挙句、結局tmpにする」という、実に平凡な悩みを抱える程度の技術者であったのだ。歳月は容赦なく流れ、今や私はプロンプトエンジニアリングという名の魔境に足を踏み入れた哀れな求道者となり果てた。昨夜も丑三つ時まで、私は薄暗い書斎でディスプレイの冷たき光に照らされながら、「なぜ生成AIは『簡潔に』と百回唱えても、源氏物語の長文を生成するのか」という哲学的難題と格闘していたのである。30分という持ち時間に対し50枚のスライドを用意するという、まるで賽の河原で石を積む如き徒労に及んでいる。そのうち半分は「プロンプトという名の現代呪術における失敗例集」と題した、私の苦悩の結晶である。ああ、AIとの対話とは、かくも人間の正気を奪うものなのか。---ブログも書いた。生成AIで物語を書くためにプロンプトの制約や原則について学ぶ、という話をしてきました #女オタ生成AI部https://syu-m-5151.hatenablog.com/entry/2025/06/30/171149

生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction 

〜日報をサボってしまう人のための解決策〜日報、めんどくさいよね正直に言います。日報書くの、めんどくさいですよね。僕も毎日終業時に「あれ、今日何やったっけ...」ってなって、GitHubでクローズしたIssue探したり、Slackでミーティングの議事録掘り返したり、Jiraのチケット確認したり...。正確に書こうとすると、気づいたら15分とか経ってるんですよね。しかも、やっと書き終わったと思ったら「あ、そういえば午前中にあのバグ直したの書き忘れた」「レビューで指摘もらった内容も書かなきゃ」みたいなことがしょっちゅう。正直、この作業が苦痛すぎて、サボっちゃう日もありました。「明日まとめて書けばいいや」って思って、結局3日分まとめて書く羽目になったり...（そして当然、細かいことは忘れてる）。でも最近、Claude Codeのカスタムslash commandsを使い始めてから、この苦行から解放されたんです。作業しながらサクッと記録できるようになって、もう日報をサボることがなくなりました。今回は、僕が実際に使ってる日報システムを紹介します。このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。Claude Codeのslash commandsって何？Claude Codeには、よく使うプロンプトをコマンド化できる機能があるんです。簡単に言うと、Markdownファイルを特定のフォルダに置くだけで、オリジナルコマンドが作れちゃいます。この機能について詳しく知りたい人は、こちらの記事がめちゃくちゃ参考になります()。syu-m-5151.hatenablog.comカスタムコマンドの仕組みから活用法、トラブルシューティングまで網羅的にまとまってて、僕も参考にさせてもらってます。特に、v1.0.25でプレフィックスが不要になったとか、frontmatterでdescription書く方法とか、知らなかったTipsがたくさんありました。で、今回はこの機能を使って日報を楽にする方法を紹介します。# こんな感じで使える/nippo-add バグ直した！僕の日報の悩みと解決策フィードバックと内省は成長に欠かせない要素です。頭では理解していても、いざ日報を書くとなると腰が重くなってしまう。「成長したい」という願望と「面倒くさい」という本音の狭間で揺れ動く——そんな矛盾を私自身も抱えています。 speakerdeck.comBefore：苦痛すぎてサボる悪循環終業時に「さて、日報書くか...」と思っても、GitHubで今日クローズしたIssueを探すSlackでミーティングの議事録を掘り返すJiraでチケットのステータス確認「あれ、午前中何してたっけ...」と記憶を辿るやっと書き始める書いてる途中で「そういえば...」と思い出して追記この作業が苦痛すぎて、つい「今日はいいや...」ってサボっちゃうんですよね。で、翌日になると、昨日の記憶があいまい「えーと、昨日の分も書かなきゃ...」さらに苦痛度アップまた今日もサボる最悪のときは3日分まとめて書く羽目に。当然、細かいことは全部忘れてて、「Issue対応しました」みたいな雑な日報になっちゃう。After：作業中にポチポチ記録Claude Codeで作業してる最中に/nippo-add バグ#123修正完了。nullチェック忘れてた。恥ずかしい...これだけ！後でAIが整形してくれるから、とりあえず記録しとけばOK。何が変わったか、その場で記録するから苦痛じゃないIssue番号もその場で記録するから探さなくていい感情も新鮮なうちに残せる/nippo-finalize で自動整形もうサボらない！（これが一番大きい）（今だけの可能性すらある）でも、日報を書く心理的ハードルがめちゃくちゃ下がりました。実際に作った3つのコマンド僕が使ってるのは、たった3つのコマンドです。実は本当はもっと詳しく作り込んでて、プロジェクト固有の処理とか、社内のテンプレートに合わせた出力とか入れてるんですが、汎用的に使えそうな部分だけ抜き出して紹介します。これでも十分使えるはず！1. /nippo-add - とにかく記録作業中に思いついたことを何でも突っ込みます。.claude/commands/nippo-add.md（またはホームディレクトリの~/.claude/commands/nippo-add.md）に以下の内容を保存：# 日報に追記する現在の日報ファイル（/tmp/nippo.$(date +%Y-%m-%d).md）に以下の内容を追記してください。## 追記する内容: $ARGUMENTSまず、日報ファイルが存在するか確認し、存在しない場合は新規作成してください。### 新規作成の場合のテンプレート:---markdown# 日報 $(date +%Y年%m月%d日)## 📝 作業ログ### $(date +%H:%M) - 初回記録$ARGUMENTS---## 🎯 今日の目標- [ ] （後で記入）## 📊 進捗状況（セッション終了時に記入）## 💡 学びと気づき（随時追記）## 🚀 明日への申し送り（本日終了時に記入）---### 既存ファイルへの追記の場合:1. 「## 📝 作業ログ」セクションを探す2. そのセクションの最後に以下の形式で追記:--markdown### $(date +%H:%M) - $ARGUMENTS の要約（20文字以内）$ARGUMENTS---### 特別な処理:- もし `$ARGUMENTS` に「振り返り:」が含まれる場合は、「## 💡 学びと気づき」セクションに追記- もし `$ARGUMENTS` に「明日:」が含まれる場合は、「## 🚀 明日への申し送り」セクションに追記- もし `$ARGUMENTS` に「目標達成:」が含まれる場合は、「## 🎯 今日の目標」セクションの該当項目にチェックを入れるポイントは、「振り返り:」とか「明日:」ってキーワードをつけると、自動的に適切なセクションに振り分けてくれること。これ、地味に便利。あと、Issue番号とかPR番号も一緒に書いておけば、後で「あれどのIssueだっけ？」ってGitHub探し回らなくて済みます。2. /nippo-finalize - AIに仕上げてもらう終業時に実行すると、散らかった作業ログから、ちゃんとした日報を作ってくれます：# 日報を完成させる本日の日報（/tmp/nippo.$(date +%Y-%m-%d).md）を完成させます。## 実行内容:1. **進捗状況の集計**   - 作業ログから本日の活動を分析   - 達成した項目と未達成の項目を整理2. **各セクションの補完**   - 空欄になっているセクションを埋める   - 作業ログから重要なポイントを抽出[以下省略...]これがすごいのは、書き忘れた「よかったこと」とか「改善点」を、作業ログから勝手に抽出してくれるところ。「あー、そういえばそれも書かなきゃ」みたいなのがなくなりました。3. /nippo-show - 確認用単純に今日の日報を表示。週次サマリーも見れます。実際の1日の流れ朝イチ$ /nippo-add スタンドアップ終了。今日は#456と#457に取り組む。#456から着手午前中のコーディング$ /nippo-add #456 実装開始。思ったより複雑...$ /nippo-add うーん、原因がわからん。デバッガで追ってみる$ /nippo-add やった！原因判明。非同期処理のタイミングの問題だった$ /nippo-add 振り返り: async/awaitの理解が甘かった。MDN読み直そうPRレビュー$ /nippo-add PR #234 レビュー完了。セキュリティ的な懸念点を指摘$ /nippo-add 自分のPR #235 もレビュー依頼出した昼休み後$ /nippo-add 定例MTG: スプリントの進捗確認。予定通り進んでることを報告$ /nippo-add 田中さんに相談したら一瞬で解決策を教えてくれた。さすが...$ /nippo-add #456 修正完了！テストも全部通った！PR作成 → #789夕方$ /nippo-add PR #789 にレビューコメントもらった。明日対応する$ /nippo-add 明日: #789のレビュー対応、#457の実装、ドキュメント更新$ /nippo-finalizeたったこれだけ！その場その場で記録するから、もうGitHubとSlackを行ったり来たりする必要なし。個人用コマンドとして設定する方法さっきのスクショにあるように、~/.claude/commands/に置けば、どのプロジェクトでも使えるようになります。これがめちゃくちゃ便利。# ホームディレクトリに個人用コマンドを作成mkdir -p ~/.claude/commandscd ~/.claude/commands# 3つのファイルを作成touch nippo-add.md nippo-finalize.md nippo-show.mdあとは上記の内容をコピペすれば完了！これの何が良いかって：- 会社のプロジェクトでも個人プロジェクトでも同じコマンド- プロジェクト切り替えても日報は一つ（/tmp/nippo-YYYY-MM-DD.mdに統一）- 複数プロジェクトまたいで作業した日も、一つの日報にまとまる実際、僕は午前中は会社のプロジェクト、午後は個人のOSS開発とかやることもあるんですが、全部一つの日報にまとまるから管理が楽です。使ってみて分かったコツ1. Issue番号やPR番号も一緒に記録後で見返すとき、めちゃくちゃ便利です。/nippo-add #456 修正完了。レビュー待ち/nippo-add PR #789 のレビュー対応完了。CIも通った！2. 恥ずかしがらずに感情も記録# これだと味気ない/nippo-add バグ修正完了# 感情も入れると後で読み返して楽しい/nippo-add バグ修正完了！3時間も悩んだけど解決してスッキリ！3. ミーティングの要点もその場でミーティング終わったら、議事録作る前にサクッと：/nippo-add 定例MTG: 来週のリリース内容確認。自分は認証機能を担当/nippo-add 振り返り: スプリントの振り返りで工数見積もりの甘さを指摘された。次は1.5倍で見積もる4. 失敗も正直に書く完璧な日報より、失敗も含めた正直な日報の方が、後で振り返ったときに学びが多いです。/nippo-add やらかした...本番DBに接続してた。幸い読み取りだけだったけど冷や汗/nippo-add 振り返り: 環境変数の確認を怠った。チェックリスト作ろう5. 細かいことでも記録「これくらい書かなくてもいいか」と思うようなことも、意外と後で役立ちます。/nippo-add VS Codeの新しい拡張機能試した。Error Lensめっちゃ便利/nippo-add TypeScriptのバージョン上げたらビルド時間が20%短縮されたトラブルシューティング「コマンドが認識されない！」僕も最初これでハマりました。原因は大体：- ファイルの拡張子が.mdじゃない（.txtにしちゃってた）- ファイル名にスペース入れちゃってる- Claude Code再起動し忘れ「$ARGUMENTSが展開されない」これも罠。$ARGUMENTSは完全一致じゃないとダメです。$arguments（小文字）とか${ARGUMENTS}（波括弧付き）は動きません。もっと自動化できるけど？究極的にはnippo-addすら自動化できるっちゃできるんですよね⋯。実際、僕も「PR作成したら自動で日報に追記」みたいなの試してみたことあります。でも結局、感情とか気づきは自分で書きたいんですよね。「やった！」とか「これハマった...」みたいな。だから今は、技術的には自動化できる部分も、あえて手動で /nippo-add してます。その方が振り返りの質が高くなる気がして。でも、チームや人によっては完全自動化もアリかも。特に定型的な作業が多いチームとか。このへんは好みと文化次第ですね。まとめ正直、このシステムを使い始めてから、日報を書くのが苦じゃなくなりました。むしろ、1日の成果を振り返るのが楽しみになってる自分がいます。一番の変化は、Before: 日報書くの面倒 → サボる → 翌日もっと面倒 → またサボる（悪循環）After: その場で記録 → 苦痛じゃない → 毎日続く → 習慣になる（好循環）特に良いのは、記憶が新鮮なうちに記録できる（Issue番号も間違えない）感情も含めて残せる（これ重要）AIが整形してくれるから、雑に書いてもOK毎日の成長が見える化される何より、サボらなくなった！(今だけだとしても)もし「日報めんどくさい...」「つい後回しにしちゃう...」「3日分まとめて書いてる...」って人がいたら、ぜひ試してみてください。最初の設定は10分もかからないし、その後の精神的な楽さを考えたら、圧倒的にコスパ良いです。あと、チームで使うとさらに面白いです。みんなの「振り返り」を読むと、「あー、そこで悩んでたのか」とか「その解決方法は思いつかなかった」とか、学びが多いんですよね。日報を「苦痛な義務」から「成長ツール」に変える。Claude Codeのslash commandsなら、それができます。Happy Logging! 🚀P.S. この記事書いてて思ったけど、ブログも/blog-addみたいなコマンド作ったら楽になりそう...今度やってみよう。というか日報をというお題からあなたの問題を解決するヒントを得てください。

Claude CodeのSlash Commandsで日報を作成する

Claude Code の .claude/commands/**.md は設定した方がいい

自己認識から自己拡張へについて.md

はじめにAIコーディングエージェント（Claude Code、Cursor、Cline等）の普及により、開発効率は飛躍的に向上しました。しかし、複数のAIエージェントを同時に使用する際、以下のような課題に直面することがあります：ファイルの競合: 複数のエージェントが同じファイルを同時に編集環境の汚染: 一つのエージェントの変更が他の作業に影響作業追跡の困難: どのエージェントが何を変更したか把握しにくいこれらの課題を解決するのが、Daggerが開発したContainer-Useです。github.comDaggerとは何かDaggerはDockerの創設者Solomon Hykes氏が2018年に立ち上げた会社で、「DevOpsオペレーティングシステム」の構築を目指しています 。コンテナで開発者の問題を解決したHykesは、今度は「CI/CDの混乱状態」という開発者とインフラの間の複雑な問題に挑戦しています 。Container-UseとはContainer-Useは、AIエージェント向けのMCP（Model Context Protocol）サーバーで、各エージェントに独立したコンテナ環境を提供します。dagger.io主要な機能隔離されたコンテナ環境: 各AIエージェントが独立した環境で動作Gitブランチによる変更管理: すべての変更が自動的にGitブランチに記録リアルタイム監視: cu watchコマンドで全環境の動作を一元監視複数環境の並列実行: 複数のエージェントが干渉することなく同時作業可能インストールと初期設定前提条件Docker（macOSの場合はColima推奨）Gitインストール方法# Homebrewを使用brew install dagger/tap/container-use# または、curlを使用curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bashgithub.comClaude Codeとの連携設定.claude/settings.local.jsonに以下を追加：{  "mcpServers": {    "container-use": {      "command": "container-use"    }  },  "permissions": {    "allow": [      "mcp__container-use__environment_open",      "mcp__container-use__environment_file_write",      "mcp__container-use__environment_run_cmd",      "mcp__container-use__environment_update"    ]  }}実際の動作例1. MCP経由でのContainer-Use操作Claude Code内でContainer-Use MCPサーバーを使用して、実際に環境を作成・操作した例です：# test-cu-demo環境を作成environment_id: test-cu-demo/polite-herring# Pythonスクリプトを作成して実行#!/usr/bin/env python3import osimport socketprint("Hello from Container-Use!")print(f"Hostname: {socket.gethostname()}")print(f"Working Directory: {os.getcwd()}")# 実行結果：# Hello from Container-Use!# Hostname: dagger# Working Directory: /workdir2. リアルタイム監視（cu watch）cu watchコマンドを実行すると、すべての環境の動作をリアルタイムで監視できます。各環境での操作（ファイル作成、コマンド実行等）が時系列で表示されます。3. Webアプリケーションの実行Container-Use内でWebアプリケーションを実行し、ポートを公開することも可能です：# 簡単なHTTPサーバーを作成from http.server import HTTPServer, BaseHTTPRequestHandlerclass SimpleHandler(BaseHTTPRequestHandler):    def do_GET(self):        self.send_response(200)        self.send_header('Content-type', 'text/html')        self.end_headers()        self.wfile.write(f'''        <html>            <body>                <h1>Hello from Container-Use!</h1>                <p>Container Hostname: {socket.gethostname()}</p>            </body>        </html>        '''.encode())# ポート8080で実行 → localhost:61753にマッピング実際に公開されたサイトのスクリーンショットでは、コンテナ内で動作するアプリケーションがブラウザから正常にアクセスできることが確認できます。基本的な使い方Container-Use MCPサーバーの主な機能Container-UseはMCPサーバーとして動作し、AIエージェントから以下の操作が可能です：environment_open: 新しい環境を作成environment_file_write: ファイルの作成・編集environment_file_read: ファイルの読み取りenvironment_run_cmd: コマンドの実行environment_update: 環境の更新（パッケージインストール等）environment_file_delete: ファイルの削除監視コマンド# リアルタイム監視cu watch# 環境一覧cu list# ログ確認cu log <環境名>まとめContainer-Useは、AIコーディングエージェントに安全で隔離された実行環境を提供する革新的なツールです。主な利点：完全な隔離: 各エージェントが独立した環境で動作透明性: すべての操作がGitブランチに記録並列性: 複数のエージェントが干渉なく同時作業安全性: メイン環境を汚染しない実験が可能AIエージェントを活用した開発をより安全で効率的にしたい方は、ぜひContainer-Useを試してみてください。参考リンクContainer-Use GitHubMCP (Model Context Protocol)Dagger公式サイト

「やっちゃえ、バーサーカー」Container-Useで実現するAIエージェントの開発環境

「実装」から「設計」へのパラダイムシフト というより無限に体力が必要という話をした #KAGのLT会

僕がClaude Codeに初めて触れたのは、2025年の春だった。生成AIにはすでに慣れ親しんでいた。流行に乗り遅れてはいけないと必死に勉強し、エディターの補完機能やコード生成ツールとして日常的に活用していた。ただ、当時の僕にとってそれはまだ「CLIで動く便利なコーディング支援ツール」程度の認識でしかなかった。「AIが90%のコードを自動生成」という謳い文句を見ても、半信半疑でターミナルを開いたのを覚えている。イベント名:【オフライン開催】KAGのLT会 #6 〜御社のエンジニア育成どうしてる!? スペシャル〜公式URL: https://kddi-agile.connpass.com/event/357862/「実装」から「設計」へのパラダイムシフト というより無限に体力が必要という話をした https://syu-m-5151.hatenablog.com/entry/2025/06/19/102529【参考文献】  - 公式ドキュメント    - Claude Code 公式サイト https://www.anthropic.com/claude-code    - Claude Code ドキュメント https://docs.anthropic.com/en/docs/claude-code/overview    - Claude Code Best Practices https://www.anthropic.com/engineering/claude-code-best-practices    - 抽象化をするということ - 具体と抽象の往復を身につける https://speakerdeck.com/soudai/abstraction-and-concretization    - How I Use Claude Code https://spiess.dev/blog/how-i-use-claude-code    - LLMの制約を味方にする開発術 https://zenn.dev/hidenorigoto/articles/38b22a2ccbeac6    - Claude Code版Orchestratorで複雑なタスクをステップ実行する https://zenn.dev/mizchi/articles/claude-code-orchestrator    - Agentic Coding Recommendations https://lucumr.pocoo.org/2025/6/12/agentic-coding/    - Claude Codeに保守しやすいコードを書いてもらうための事前準備 https://www.memory-lovers.blog/entry/2025/06/12/074355    - Claude Codeによる技術的特異点を見届けろ https://zenn.dev/mizchi/articles/claude-code-singularity-point

Claude Code どこまでも/ Claude Code Everywhere

自動承認

技術的負債の変質について

Claude Code の CLAUDE.mdは設定した方がいい

IntroductionAs developers, we often juggle multiple contexts throughout our day - switching between personal projects, client work, and perhaps some experimental code on the side. Each context might require different permissions, access levels, and configurations. If you're using Claude Code, Anthropic's CLI tool for interacting with Claude, you've probably felt the pain of manually managing different settings.json configurations. That's why I built cctx - a fast, intuitive context switcher for Claude Code, inspired by the excellent kubectx tool for Kubernetes.github.comThe Problem: Configuration Context SwitchingClaude Code uses a settings.json file to control permissions, access levels, and various configurations. This is great for security and customization, but becomes cumbersome when you need different settings for different scenarios:Work projects need restricted permissions for safetyPersonal projects might need full access to your file systemClient demos require ultra-restricted settings for screen sharingExperimental work needs different tool accessManually editing settings.json or maintaining multiple copies quickly becomes error-prone and tedious. I needed something better.docs.anthropic.comEnter cctx: Fast Context Switching for Claude Codecctx (Claude Context) brings the simplicity and speed of kubectx to Claude Code configuration management. Written in Rust for maximum performance, it allows you to switch between different Claude Code configurations with a single command:# Switch to work context (restricted permissions)cctx work# Switch to personal context (full permissions)cctx personal# Switch back to previous contextcctx -Design Philosophy: Predictable Defaults with Progressive DisclosureOne of the key lessons learned during development was the importance of predictable behavior. In version 0.1.1+, I completely redesigned the UX around a simple principle: predictable defaults with explicit overrides.What This Means in PracticeDefault behavior is always the same - cctx always manages user-level contexts (~/.claude/settings.json) unless explicitly told otherwiseNo surprising auto-detection - The tool won't suddenly switch to project-level contexts just because you're in a different directoryProgressive disclosure - When project or local contexts are available, helpful hints guide you to themExplicit when needed - Use --in-project or --local flags when you want to manage other context levelsThis approach eliminates cognitive overhead while maintaining full functionality for advanced users.Key Features That Make cctx Shine🚀 Lightning FastBuilt with Rust, cctx switches contexts in milliseconds. No Python startup overhead, no Node.js dependencies - just pure speed.🎨 Beautiful, Intuitive InterfaceColor-coded output with the current context highlighted in greenHelpful emoji indicators for different context levels (👤 User, 📁 Project, 💻 Local)Interactive fuzzy search with fzf integration or built-in finderClear, actionable error messages🛡️ Security-First DesignCreate separate contexts for different security requirements:# Create a restricted work contextcctx -n workcctx -e work  # Edit to add restrictions# Create a demo context for screen sharingcctx -n demo  # Ultra-restricted, read-only📁 Simple File-Based StorageContexts are just JSON files stored in ~/.claude/settings/. You can edit them manually, version control them, or sync them across machines.Real-World Usage PatternsHere's how I use cctx in my daily workflow:Morning Routine# Start the day with work contextcctx work# Check what context I'm incctx -c# Output: workProject Switching# Working on a personal projectcctx personal# Client calls - need to share screencctx demo# Back to personal projectcctx -Context Management# Create a new context for a specific clientcctx -n client-acme# Edit the context to set appropriate permissionscctx -e client-acme# List all contextscctx# Output:# 👤 User contexts:#   client-acme#   demo#   personal#   work (current)Technical Implementation HighlightsWhy Rust?Performance: Instant startup and executionSafety: Memory safety without garbage collectionSingle binary: Easy distribution and installationGreat ecosystem: Excellent CLI libraries like clap and dialoguerArchitecture DecisionsFile-based contexts: Each context is a separate JSON fileAtomic operations: Context switching is done by copying filesState tracking: Current and previous contexts tracked in a hidden state filePlatform compatibility: Works on Linux, macOS, and WindowsSettings Hierarchy Supportcctx respects Claude Code's settings hierarchy while keeping things simple:# Default: user-level contextscctx work# Explicit: project-level contextscctx --in-project staging# Explicit: local project contextscctx --local debugGetting StartedInstallation is straightforward:# From crates.io (recommended)cargo install cctx# Or grab a pre-built binary# Download from https://github.com/nwiizo/cctx/releasesCreate your first contexts:# Create a personal context from current settingscctx -n personal# Create a restricted work contextcctx -n workcctx -e work  # Edit to add restrictions# Start switching!cctx workcctx personalcctx -  # Switch backWhat's Next?The cctx project is actively maintained and follows Claude Code's development closely. Some ideas for the future include:Context templates for common scenariosShell integration for automatic context switchingContext inheritance for shared settingsIntegration with other AI coding toolsConclusioncctx brings the joy of quick context switching to Claude Code users. By focusing on speed, simplicity, and predictable behavior, it removes the friction from managing multiple configurations. Whether you're switching between work and personal projects, managing client-specific settings, or just want better control over your Claude Code permissions, cctx has you covered.The project is open source and available on GitHub. If you find it useful, please consider starring the repository and contributing your own ideas and improvements. Happy context switching!cctx is an independent open-source project and is not affiliated with Anthropic. For official Claude Code documentation and support, please visit docs.anthropic.com.

Introducing cctx: A Context Switcher for Claude Code

はじめにClaude Code 使ってますか？ターミナルから Claude に直接コーディングタスクを投げられる便利なツールなんですが、デフォルト設定のまま使うのはちょっともったいない。というかいちいちいろんなことを聞いてきてめちゃくちゃダルい。syu-m-5151.hatenablog.comsettings.json をちゃんと設定すると、セキュリティも保ちつつ、もっと快適に使えるようになります。全体的に疲れている時の~/.claude/settings.json と~/.claude/CLAUDE.md · GitHub 私のデフォルトの設定も公開してますのでよかったら参考にしてください。ここで読むのをやめる人のために言っておくと Claude Codeの設定は優先順位があるので覚えておくと良い です。あと、比較的に今は黎明期なので非推奨や追加機能が多いのでその点も注意が必要かもです。正直なところ、Anthropic の公式ドキュメント（日本語）が最高に分かりやすいので、まずはそっちを読んでほしいんですが、このブログは公式ドキュメントに赤線を引いたようなもので、実際に使ってみて「これは設定しといた方がいいよ」っていうポイントをピックアップしてまとめました。docs.anthropic.comsettings.json って何？settings.json は Claude Code の動作を制御する設定ファイルです。公式ドキュメントによると、こんな設定ができます。{  "permissions": {    "allow": [      "Bash(npm run lint)",      "Bash(npm run test:*)",      "Read(~/.zshrc)"    ],    "deny": [      "Bash(curl:*)"    ]  },  "env": {    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",    "OTEL_METRICS_EXPORTER": "otlp"  }}設定できる項目 キー  説明  例  apiKeyHelper  Anthropic APIキーを生成するカスタムスクリプト  /bin/generate_temp_api_key.sh  cleanupPeriodDays  チャット記録をローカルに保持する期間（デフォルト：30日）  20  env  すべてのセッションに適用される環境変数  {"FOO": "bar"}  includeCoAuthoredBy  gitコミットにco-authored-by Claudeを含めるか（デフォルト：true）  false  permissions  ツールのアクセス権限設定  後述 権限設定をちゃんとやろうClaude Code の一番重要な機能がこの権限設定。/permissions コマンドで現在の設定を確認できます。/permissionsはとても良いので覚えておいてほしいです。また、便利なCLIの使い方も覚えておいたほうが多分良いです。docs.anthropic.comBash コマンドの制御{  "permissions": {    "allow": [      "Bash(npm run build)",      // 特定のコマンドだけ許可      "Bash(npm run test:*)",     // プレフィックスで許可      "Bash(git:*)"               // git コマンドは全部OK    ],    "deny": [      "Bash(curl:*)"              // curl は使わせない    ]  }}Claude Code はシェル演算子（&&など）も認識してるので、Bash(safe-cmd:*)みたいなルールでもsafe-cmd && dangerous-cmdみたいなのは実行できません。賢い！ファイルアクセスの制御Read と Edit のルールは gitignore の仕様に従います：{  "permissions": {    "allow": [      "Edit(docs/**)",           // プロジェクトの docs ディレクトリ内を編集可能      "Read(~/.zshrc)",         // ホームディレクトリの .zshrc を読める      "Edit(//tmp/scratch.txt)" // 絶対パスは // で指定    ]  }}Web アクセスの制御{  "permissions": {    "allow": [      "WebFetch(domain:example.com)"  // 特定ドメインのみ許可    ]  }}環境変数の活用公式ドキュメントに載ってる環境変数をうまく使うと便利：{  "env": {    "ANTHROPIC_API_KEY": "your-key-here",    "CLAUDE_CODE_ENABLE_TELEMETRY": "0",    "DISABLE_COST_WARNINGS": "1",    "BASH_DEFAULT_TIMEOUT_MS": "300000",    "BASH_MAX_TIMEOUT_MS": "1200000"  }}主要な環境変数 変数名  用途  CLAUDE_CODE_ENABLE_TELEMETRY  テレメトリの有効/無効  DISABLE_COST_WARNINGS  コスト警告を無効化  BASH_DEFAULT_TIMEOUT_MS  Bashコマンドのデフォルトタイムアウト  DISABLE_AUTOUPDATER  自動更新を無効化 設定の優先順位を理解しよう公式ドキュメントによると、設定は以下の順番で適用されます（上が優先）：エンタープライズポリシーコマンドライン引数ローカルプロジェクト設定（.claude/settings.local.json）共有プロジェクト設定（.claude/settings.json）ユーザー設定（~/.claude/settings.json）プロジェクトごとに設定を変えたければ、プロジェクトフォルダに .claude/settings.json を置けばOK。Git で共有したくない設定は .claude/settings.local.json に書こう。実践的な設定例制限的な設定（仕事用）{  "permissions": {    "allow": [      "Bash(npm run lint)",      "Bash(npm run test:*)",      "Bash(git:*)",      "Read(./src/**)",      "Edit(./src/**)"    ],    "deny": [      "Bash(npm publish:*)",      "WebFetch(domain:*)"    ]  },  "includeCoAuthoredBy": false}もう少しゆるい設定（個人用）{  "permissions": {    "allow": [      "Bash(npm:*)",      "Bash(git:*)",      "Bash(cargo:*)",      "Read(**)",      "Edit(~/projects/**)",      "WebFetch(domain:*)"    ]  },  "cleanupPeriodDays": 60}MCP (Model Context Protocol) を使う場合MCP サーバーを使ってる人向けの権限設定：{  "permissions": {    "allow": [      "mcp__puppeteer",                        // puppeteer サーバーの全ツール      "mcp__puppeteer__puppeteer_navigate"     // 特定のツールだけ    ]  }}複数の設定を切り替えたいならちなみに、複数の~/.claude/settings.jsonを簡単に切り替えたい人向けに cctx っていうツールも作ってみました。cargo install cctxまとめClaude Code の settings.json は、ちゃんと設定すると作業効率とセキュリティが大幅に向上します。ちゃんとしましょう。特に重要なのは：権限設定で必要最小限のアクセスだけ許可するプロジェクトごとに適切な設定を使い分ける環境変数でタイムアウトやテレメトリを調整する詳しい設定方法は Anthropic の公式ドキュメント（日本語）がマジで分かりやすいので、ぜひ読んでみてください。Anthropic の公式ドキュメント最高！Claude Code の 公式ドキュメントやベストプラクティス はとりあえず読んだ方がいい。www.anthropic.com参考リンクClaude Code 公式ドキュメント（日本語） - これ読めば全部分かるcctx - Claude Context Manager - 設定切り替えツールClaude Code 設定例（Gist） - 実際の設定例

Claude Code の settings.json は設定した方がいい

はじめに生成AIを使ったコード開発が急速に普及している。GitHub Copilot、ChatGPT、Claude、そして各種IDEに統合されたAIアシスタントや独立したコーディングエージェント。これらのツールは開発効率を飛躍的に向上させ、もはやAIなしでの開発は考えられないという声も聞こえてくる（主に心の底から）。しかし、この革新的な変化の中で、看過できない問題が顕在化している。現在のAIで生成したコードは、2年後の進化したAIで再生成すれば、より効率的で保守性の高いコードに置き換えられる。これ自体は技術進歩として歓迎すべきことだが、重要な情報が失われている。それは「なぜそのコードをそのように実装したのか」という意思決定の記録だ。この問題は単なる技術的な課題ではない。私たちがどのようにソフトウェアを作り、保守し、進化させていくかという、エンジニアリングの本質に関わる問題だ（そして、2年後の自分に恨まれない方法でもある）。プロンプトと成果物の分離がもたらす課題従来の開発では、コードとともにコメントやドキュメントで意図を残してきた。しかしAI時代では、以下の情報が分離してしまう：入力：プロンプト（要件、制約、背景情報）出力：生成されたコード生成されたコードだけがリポジトリに残り、そのコードを生成した際のプロンプトや文脈は失われる。2年後、より優れたAIでコードを改善しようとしても、元の要件や制約条件、設計判断の根拠が不明なため、適切な改善ができない。これは「なんでこんな実装になってるの？」と聞かれて「AIがそう書いたから...」としか答えられない悲しい未来への第一歩だ。ADRからPDRへ：解決策の提案ソフトウェアアーキテクチャの分野では、ADR（Architecture Decision Records）によって設計判断を記録する文化が定着している。同様に、AI時代にはPDR（Prompt Decision Records）が必要だ。syu-m-5151.hatenablog.comPDRに記録すべき要素：使用したAIモデルとバージョン（GPT-4なのかClaude-3なのか、未来の自分は知りたがっている）入力したプロンプトの完全なテキストプロンプトに込めた意図と背景検討した他の選択肢採用した理由とトレードオフ生成パラメータ（temperature、max_tokens等）既存ツールにおける実装例既存ツールの現状についてはこちらがめちゃくちゃよくまとまっております。azukiazusa.devCursor Rulesdocs.cursor.comCursorでは.cursorrulesファイルでプロジェクト固有のコンテキストを定義できる。これにより、AIは常にプロジェクトの規約や方針を理解した上でコードを生成する（理解しているフリをすることもあるが）。具体的には、プロジェクトのルートディレクトリに.cursorrulesファイルを配置することで、以下のような指示を永続化できる：このプロジェクトではTypeScriptを使用し、関数型プログラミングのアプローチを優先する。エラーハンドリングはResult型を使用し、例外は投げない。すべての関数にはJSDocコメントを必須とする。このファイルはプロジェクト全体で共有される暗黙知を形式知化する役割を果たし、新しいメンバーがジョインした際のオンボーディングツールとしても機能する。Cline Rulesdocs.cline.botClineも同様に、プロジェクトルールを定義する仕組みを提供している。これらのルールファイルは、実質的にプロンプトの一部を永続化する仕組みだ。Clineの特徴的な点は、ルールを階層的に管理できることだ。グローバルルール、プロジェクトルール、ディレクトリ固有のルールを定義でき、より細かい粒度でAIの振る舞いを制御できる。例えば：/backendディレクトリ：「APIエンドポイントはRESTfulな設計に従う」/frontendディレクトリ：「ReactコンポーネントはHooksを使用した関数コンポーネントとする」/testsディレクトリ：「テストはAAA（Arrange-Act-Assert）パターンに従う」このようなコンテキストの階層管理により、大規模プロジェクトでも一貫性を保ちながら、部分ごとに最適化されたAI支援を受けられる。Anthropic CLAUDE.mdwww.anthropic.comAnthropicのCLAUDE.mdアプローチは、プロジェクトの全体的なコンテキストを単一のマークダウンファイルにまとめる。これは包括的なプロンプトテンプレートとして機能し、AIとの対話の基盤となる。CLAUDE.mdの強みは、単なるルールの羅列ではなく、プロジェクトのストーリーを語る点にある。典型的な構成は：# プロジェクト概要このプロジェクトの目的と背景# アーキテクチャシステムの全体構成と主要コンポーネントの説明# 開発規約- コーディングスタイル- 命名規則- ディレクトリ構造# よくある質問と回答過去の設計判断とその理由この形式により、AIは単にルールに従うだけでなく、プロジェクトの「なぜ」を理解した上でコードを生成できる。まさに本記事で提唱するPDRの考え方を先取りした実装と言えるだろう。実装における具体的な課題バージョン管理プロンプトもコードと同様にバージョン管理が必要だ。しかし、以下の課題がある：プロンプトの変更がコードに与える影響の追跡AIモデルのバージョンアップに伴う互換性管理プロンプトとコードの紐付けの維持（gitのblameコマンドに「AI」と表示される悲しさ）標準化の欠如現状、プロンプトを記録・管理する標準的な方法は存在しない。各ツールが独自の方法を実装しているため、ツール間での移植性がない。まるで文字コードの乱立時代を彷彿とさせる。再現性の問題同じプロンプトでも、以下の要因により出力が変わる：AIモデルのバージョン生成パラメータAPIのバージョン実行タイミング（モデルの更新）今後の展望と提案短期的な対策既存ツールの活用Cursor、Cline、GitHub Copilotなどが提供するルールファイル機能を積極的に活用し、プロジェクト固有のコンテキストを記録・管理する。プロンプトのコメント埋め込み生成されたコードに、使用したプロンプトをコメントとして埋め込む（将来の自分への手紙として）。専用ディレクトリでの管理/promptsディレクトリを作成し、コードファイルと対応するプロンプトファイルを保存。生成メタデータの記録生成日時、モデルバージョン、パラメータをJSONで保存。中長期的な標準化業界標準として、以下のような仕様が必要になるかもしれない：# prompt-decision-record.yamlversion: 1.0timestamp: 2024-12-XXmodel:  provider: openai  name: gpt-4  version: gpt-4-0125-preview  mood: cooperative  # 冗談ですparameters:  temperature: 0.7  max_tokens: 2000prompt: |  実際のプロンプトテキストcontext:  requirements: |    要件の説明  constraints: |    制約事項  decisions: |    設計判断の根拠output_file: src/feature/***.pyおわりにAI活用が当たり前になる開発環境において、コードの「なぜ」を残すことは、技術的負債を防ぐ重要な実践だ。2年後により良いAIが登場したとき、過去の意思決定を理解できれば、真に価値のある改善が可能になる。私たちエンジニアは、常に未来の自分や同僚のことを考えてコードを書いてきた。可読性、保守性、拡張性—これらはすべて「未来の誰か」のための配慮だ。AI時代においても、この精神は変わらない。むしろ、AIの進化速度を考えれば、より一層重要になる。プロンプトは新しい形の設計書だ。コードレビューと同じように、プロンプトレビューが必要になるかもしれない。リファクタリングと同じように、プロンプトリファクタリングが日常になるかもしれない（プロンプトの可読性を議論する日も近い）。もしくはそのような考慮をすべて超えて全てを理解する生成AIのモデルが成長する可能性もある。PDRのような仕組みの標準化は、AI時代のソフトウェア開発における必須要件となるだろう。エンジニアとして、この課題に真剣に取り組む時期に来ているが、個人ではどうにもならない気もするので。頑張れ、Anthropic！！！

AIが進化しても、なぜそのコードを書いたかは消えていく

なぜmarp.nvimが必要だったのか前回の記事でClaude Codeに移行し、Neovimに完全回帰することを決めた。コーディング、ドキュメント作成、設定ファイルの編集――すべてが再びターミナルで完結するようになった。しかし、一つだけ問題があった。Marpでのプレゼンテーション作成だ。Marpは素晴らしいツールだが、公式のNeovimサポートは存在しない。プレゼンテーションを作るたびに、仕方なくVSCodeやCursorを起動していた。せっかくNeovimに完全回帰したのに、プレゼン作成のためだけに別のエディタを立ち上げる。この矛盾が許せなかった。marp.app既存のソリューションを探したが、満足できるものはなかった。ならば答えは一つ――自作するしかない。こうしてmarp.nvimは生まれた。Neovimですべてを完結させるという理想を、妥協なく追求した結果だ。github.commarp.nvimの技術的アプローチアーキテクチャ┌─────────────┐     ┌─────────────┐     ┌─────────────┐│   Neovim    │────▶│  marp.nvim  │────▶│  Marp CLI   ││   Buffer    │     │  Lua Plugin │     │  --watch    │└─────────────┘     └─────────────┘     └─────────────┘                            │                            ▼                    ┌─────────────┐                    │   Browser   │                    │  Auto-open  │                    └─────────────┘コア実装の詳細1. Marp CLIのプロセス管理これは完全にMarp の作者が優秀なのですがMarpには--watchオプションが存在しています。これを使わない手はないです-- プロセスをバッファごとに管理M.active_processes = {}-- jobstart で Marp CLI を起動local job_id = vim.fn.jobstart(shell_cmd, {    pty = true,  -- 擬似端末で適切な出力キャプチャ    stdout_buffered = false,    stderr_buffered = false,    on_stdout = function(_, data)        -- 出力処理    end,    on_exit = function()        M.active_processes[bufnr] = nil    end})重要なポイント：pty = trueを使用することで、Marp CLIのカラー出力を適切に処理stdout_buffered = falseでリアルタイム出力を実現バッファ番号をキーにしてプロセスを管理2. 自動クリーンアップの実装vim.api.nvim_create_autocmd({"BufDelete", "BufWipeout"}, {    buffer = bufnr,    once = true,    callback = function()        M.stop(bufnr)    end})VSCode拡張機能では当たり前の機能だが、Neovimでは自前実装が必要。バッファのライフサイクルに合わせてプロセスを管理。3. ウォッチモード vs サーバーモードif M.config.server_mode then    cmd = string.format("%s -s '%s'", marp_cmd, file)else    -- デフォルトは --watch モード    cmd = string.format("%s --watch '%s'", marp_cmd, file)end2つのモードをサポート：ウォッチモード（デフォルト）: HTMLファイルを生成し、変更を監視サーバーモード: HTTPサーバーを起動（ポート競合の可能性あり）4. ANSIエスケープシーケンスの処理local function clean_ansi(str)    return str:gsub("\27%[[%d;]*m", ""):gsub("\27%[[%d;]*[A-Za-z]", "")endMarp CLIの美しいカラー出力をNeovimの通知システムで扱うための処理。これがないと文字化けする。実装で工夫した点1. 初回HTML生成の最適化-- ウォッチモード開始前に初回HTMLを生成if not M.config.server_mode then    local init_cmd = string.format("%s '%s' -o '%s'", marp_cmd, file, html_file)    vim.fn.system(init_cmd)        if vim.fn.filereadable(html_file) == 1 then        -- 即座にブラウザを開く        M.open_browser("file://" .. html_file)    endend--watchモードは初回生成が遅いため、事前に生成してUXを改善。2. クロスプラットフォーム対応function M.open_browser(url)    local cmd    if vim.fn.has("mac") == 1 then        cmd = "open " .. url    elseif vim.fn.has("unix") == 1 then        cmd = "xdg-open " .. url    elseif vim.fn.has("win32") == 1 then        cmd = "start " .. url    end    vim.fn.jobstart(cmd, {detach = true})end3. デバッグモードM.config = {    debug = true,  -- 詳細ログを有効化}-- :MarpDebug コマンドで診断function M.debug()    local test_cmd = string.format("%s --version", marp_cmd)    -- Marp CLIの動作確認endトラブルシューティングを容易にするため、詳細なログ出力機能を実装。VSCode拡張機能との機能比較 機能  Marp for VS Code  marp.nvim  ライブプレビュー  ✅  ✅  自動リロード(書き込みイベント時)  ✅  ✅  テーマ切り替え  GUI  :MarpTheme  エクスポート  GUI  :MarpExport  スライドナビゲーション  ✅  ❌（開発中）  スニペット  ✅  ✅  複数ファイル同時編集  ✅  ✅ 使用方法インストール-- lazy.nvim{    "nwiizo/marp.nvim",    ft = "markdown",    config = function()        require("marp").setup({            marp_command = "npx @marp-team/marp-cli@latest",            debug = false,            server_mode = false,  -- ウォッチモードを使用        })    end,}基本的なワークフロー:e presentation.md:MarpWatch          " プレビュー開始(ファイル名をClipboardに書き込みもしている):MarpTheme uncover  " テーマ変更:MarpExport pdf     " PDF出力:q                  " バッファを閉じると自動でサーバー停止トラブルシューティング:MarpDebug          " Marp CLIの動作確認:MarpList           " アクティブなサーバー一覧:MarpStopAll        " 全サーバー停止パフォーマンスと制限事項メモリ使用量Marp CLIプロセス: 約50-100MB/インスタンス複数ファイル同時編集時は線形に増加既知の制限ホットリロードの遅延: ファイル保存からブラウザ更新まで約100-200ms大規模ファイル: 100スライド以上でパフォーマンス低下画像の相対パス: 作業ディレクトリに依存まとめmarp.nvimの開発により、Marpプレゼンテーション作成のためだけにCursorを起動する必要がなくなった。Neovimのjob APIを活用することで、VSCode拡張機能と似た体験を実現できることを証明できた。重要なのは、完璧を求めすぎないこと。VSCode拡張機能のすべての機能を再現する必要はない。ターミナルでの開発に必要十分な機能を、シンプルに実装することが大切だ。Claude Codeとの組み合わせで、プレゼンテーション作成もAIアシスト付きで行える。これで本当にすべての開発作業をNeovimで完結できるようになった。vimmer村への完全帰還、達成。実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所Amazon

marp.nvimを開発してCursorから完全移行した話

はじめに前回、「NeovimをCursorのように進化させる - yetone/avante.nvim の導入」を書いた。あの記事では、まるで自分だけの剣を鍛え上げていくように、エディターと共に成長していくPDEの哲学について語った。syu-m-5151.hatenablog.comあれから数ヶ月、私のNeovimはavante.nvimによってCursor + Roo-Codeライクな体験を手に入れ、PDEとしてさらなる進化を遂げた。しかし、告白しなければならないことがある。vimmerを自称しながら、実は日常的にCursorを使っていた。この矛盾と向き合う時が来た。www.cursor.comそして先週の土曜日、私はClaude Codeを使い始めた。今日で1週間。短い期間だが、これが私のPDEに新たな可能性をもたらすことを確信している。そして、Cursor のサブスクを解約してClaude をMAX Planにした。www.youtube.com私は、Claude Code を利用しようと思っているのでvimmer が住む村に帰ろうと思います。一旦、お別れです。 pic.twitter.com/Is5fAUD5hI— nwiizo (@nwiizo) 2025年5月29日   「いいえ、Neovimはもっと強くなれます」前回からの旅路：PDEという哲学前回の記事で、私はこう書いた：Neovimの最大の魅力は、その圧倒的なカスタマイズ性。それは単なるIDE（統合開発環境）ではなく、PDE（Personal Development Environment：個人開発環境）とも呼べる存在です。この言葉は、今思えば預言的だった。PDEという概念は、単にツールをカスタマイズすることではない。それは、開発者が自分自身の思考プロセスと一体化したツールを作り上げることだ。まるで自分だけの剣を鍛え上げていくように、エディターと共に成長していく。そして今、私は気づいた。PDEとは、一人で剣の丘で鉄を鍛つような孤独で崇高な作業なのだと。誰かが用意した完成品ではなく、自分の手で、自分のために、一つ一つ形作っていくもの。avante.nvimは、その第一歩だった。しかし、6ヶ月間Cursor + Roo-Codeを使い込んだことで、私は逆説的にPDEの価値を理解した。Cursor + Roo-Codeは確かに完成度の高い「製品」だ。しかし、私が求めていたのは「作品」—自分の手で育てていけるものだった。実際には育ててなくても育てている感覚があるものだ。正直に告白しよう。vimmerを自称しながらも、実は各所でCursor + Roo-Codeを使っていた。クライアントワークでは生産性を優先してCursor、個人プロジェクトではNeovim。そんな二重生活を送っていた。この矛盾に、私自身も気づいていた。なぜ今、Claude Codeなのか正直に言えば、Claude Codeを使い始めた最大の理由は、Claude Opus 4がリリースされたからだ。最新にして最強のモデル。その能力を、私の愛するターミナル環境で直接使えるなんて—これは試さずにはいられなかった。zenn.devしかし、それだけではない。Claude Codeが掲げる「Terminal Velocity」という概念に、私は強く惹かれた。www.anthropic.com考えてみてほしい。私たちvimmerは、なぜターミナルから離れないのか？それは、思考の流れを断ち切りたくないからだ。GUIアプリケーションへの切り替え、マウスへの手の移動、異なるUIパラダイムへの適応—これらすべてが、私たちの集中を妨げる。Claude Codeは、その問題を根本から解決する。「コンテキストスイッチをゼロにする」—これは、PDEの究極の形かもしれない。そしてもう一つ、個人的に重要だったのがMAX Planという料金体系だ。トークン数無制限。これは貧乏性の私にとって革命的だった。Cursorでは常に「今月あとどれくらい使えるか」を気にしていた。コーディングエージェントでコードを書く前に「これ、AIに聞くほどの価値があるかな？」と躊躇する。そんな心理的ブレーキが、創造性を阻害していたことに気づいた。MAX Planは、その制限から私を解放してくれた。思考のままに、遠慮なくAIと対話できる。まるで無限のメモ帳を手に入れたような感覚だ。「トークンがもったいない」という貧乏性マインドから解放されて初めて、本当の意味でAIとの協働が始まる。これこそが、私のメンタルモデルと完璧に合致した。先週土曜日から使い始めて、まだ1週間。しかし、その短い期間でも、Claude Codeの持つ独特の「控えめな賢さ」に魅了された。Roo-Codeのような積極性はない。しかし、それがかえって心地よい。必要な時に、必要なだけ、的確な支援をしてくれる。Claude Opus 4の高い理解力が、控えめながらも的確なアドバイスを可能にしているのだろう。そして何より、もうトークン数を気にする必要がない。深夜のコーディングセッションで「あと何回質問できるかな...」と計算する必要もない。この精神的な自由度が、私の開発スタイルを根本から変えつつある。zenn.devzenn.devnote.comCursor + Roo-Codeへの敬意、そして決別誤解しないでほしい。私はCursor + Roo-Codeを否定したいわけではない。実際、この6ヶ月間、私は久しぶりにVSCodeベースのCursorをメインエディタとして使い込んだ。そしてそれは、驚くほど素晴らしい体験だった。特にRoo-Codeとの組み合わせで実感したのは、これは単にAIモデルを統合しただけのツールではないということだ。それは開発体験そのものが根本的に違う。github.com考えてみてほしい。従来の開発では、私たちは一つのファイルを開き、一行ずつコードを書いていた。しかしCursor + Roo-Codeの世界では、コードベース全体が一つの有機体として扱われる。「このコンポーネントをリファクタリングして」と言えば、関連する全てのファイルが瞬時に更新される。「このテストを追加して」と言えば、適切なディレクトリに適切な形式でテストが生成される。さらに驚くべきは、Roo-Codeが持つ「意図の理解」だ。曖昧な指示でも、プロジェクトの文脈を読み取り、開発者が本当に必要としているものを推測して提案してくる。それは、経験豊富な同僚とペアプログラミングをしているような感覚だった。これは単なる効率化ではない。これは開発の概念そのものの再定義だった。正直に言えば、これほど生産的な6ヶ月は久しぶりだった。前回の記事でavante.nvimを導入したのも、このCursor + Roo-Codeの革新的な開発体験に触発されたからこそだった。6ヶ月のCursor + Roo-Code体験は、確かに私の開発スタイルを変えた。Tab補完を超えた、AIペアプログラミング。しかし同時に、ある種の違和感も育っていった。それは、自分がコードを「書いている」のか「選んでいる」のか、境界が曖昧になる感覚だった。そして、もう一つの違和感。朝はNeovimで始めたはずが、気がつけばCursorを開いている。締切が迫ると、つい効率的な方を選んでしまう。vimmerとしてのアイデンティティが揺らいでいた。この6ヶ月は、技術的な進歩と同時に、自分自身との葛藤の期間でもあった。Roo-Codeが見せてくれた「開発体験の違い」は革新的だった。しかし、それゆえに気づいたことがある。開発者として長年培ってきた直感が教えてくれる。私たちには「まだ形になっていないアイデアを、コードという形で具現化する」という独特の能力がある。AIはコードを生成できる。しかし、なぜそのコードが必要なのか、それが解決すべき本質的な問題は何かを理解することはできない。そして今、6ヶ月の濃密な体験を経て、私は確信を持って言える—Cursor + Roo-Codeは素晴らしい。その組み合わせは革命的だ。しかし、私にはPDEとしてのNeovimがある。それは単なるエディタではなく、私の思考の延長線上にある道具なのだ。PDEの完成形を目指してしかし、正直に言えば、この6ヶ月はNeovimとCursorの間で揺れ動いていた。月曜の朝は「今週こそNeovimで」と決意するも、水曜には締切に追われてCursorを開く。金曜には罪悪感を感じながらも、Roo-Codeの生産性に頼っていた。vimmerとしての矜持はどこへ行ったのか。だが、この葛藤の中で私は気づいた。PDEとは、単に優れたツールを集めることではない。それは、自分の開発哲学と完全に一致した環境を構築することだ。そして今、NeovimコミュニティはAI時代に適応し、驚くべき進化を遂げている。以下に紹介する3つのプラグインは、その進化の最前線にある。yetone/avante.nvim - 前回の記事で導入したこのプラグインは、Cursor AI IDEの体験をNeovimで完璧に再現する。サイドバーでのAI対話、差分の視覚的表示、ワンクリックでのコード適用など、Cursor + Roo-Codeユーザーが慣れ親しんだ機能をすべて提供する。しかし、それだけではない。Neovimのモーダル編集と完全に統合されているため、思考の流れを妨げることなくAIとの対話を行える。ravitemer/mcphub.nvim - AnthropicのModel Context Protocol (MCP)をNeovimに統合する革新的なプラグイン。MCPサーバーの集中管理により、AIが外部ツールやデータソースにシームレスにアクセスできるようになる。データベースへの直接クエリ、ファイルシステムの操作、外部APIとの連携—これらすべてがNeovimの中で完結する。これこそが、未来のAI開発環境の標準となるだろう。こちらでMCP経由でもclaude-codeを利用している。greggh/claude-code.nvim - Claude Code CLIとNeovimを完全に融合させる野心的なプロジェクト。ターミナル内でClaude Opus 4を含む最新モデルの全能力を解き放ち、まさに「Terminal Velocity」を体現する。:ClaudeCodeコマンド一つで、現在のバッファやプロジェクト全体のコンテキストを理解した上で、最適な提案を行ってくれる。これは単なるプラグインではない—開発体験の再定義だ。これらのツールを組み合わせることで、私のNeovimは単なるテキストエディタから、真のAI統合開発環境へと進化した。もはやCursorを羨む必要はない。むしろ、より深く、より個人的な形でAIと協働できる環境が、ここにある。github.comPDEという哲学の深化PDEとは何か。それは、開発者の思考パターンとツールが完全に一体化した環境だ。前回の記事で初めてこの概念を提示したが、6ヶ月の実践を経て、その意味がより深く理解できるようになった。筆者は専門家ではないため、あくまで個人的な経験に基づく話として聞いていただきたいが、優れたPDEには以下の特徴がある：思考の流れを妨げない：Warp + Neovim + Claude Codeの組み合わせ拡張可能性：新しいツールを取り込める柔軟性個人の哲学の反映：設定ファイルという形での思想の具現化私の~/.config/nvim/lua/plugins/init.luaは、単なる設定ファイルではない。これは私の開発思想の結晶だ。Lazy.nvimを通じて管理されるプラグインの一つ一つが、私の開発哲学を体現している。Cursor + Roo-Codeの体験を経て、その設定はさらに洗練された。そして何より、PDEの構築は一人で剣の丘で鉄を鍛つ行為に似ている。誰も代わりにはできない。自分の手で、自分のために、ひたすら打ち続ける。時に孤独で、時に苦しい。しかし、その先に待っているのは、自分だけの、世界に一つだけの剣だ。Cursor + Roo-Codeが示してくれた新しい開発体験は、確かに革新的だった。しかし、それらは「完成品」だ。一方、PDEとしてのNeovimは「進化し続ける生き物」のようなものだ。私の成長と共に、私の理解と共に、そして私の哲学と共に変化していく。この1週間、Claude Codeを使いながら感じたのは、「これこそが私の求めていたAIとの距離感だ」ということだった。過度に依存せず、しかし必要な時には頼れる。まさに理想的なパートナーシップだ。そして何より、もう環境を使い分ける必要がない。朝から晩まで、クライアントワークも個人プロジェクトも、すべてを私のPDEで完結できる。この統一感が、開発者としての一貫性を取り戻してくれた。おわりに前回の記事から始まった旅は、今、新たな段階に入った。avante.nvimで手に入れたCursor + Roo-Codeライクな体験に、Claude Codeの「Terminal Velocity」が加わることで、私のPDEは更に進化した。興味深いのは、最先端を追求した結果、最も原始的なツール—ターミナルとテキストエディタ—に戻ってきたことだ。しかし、これは後退ではない。これは螺旋的な進化だ。AIとの協働が当たり前になる時代において、私たちに必要なのは、AIとの適切な距離感を保ちながら、共に新たな地平を切り開いていく勇気かもしれない。そして、その第一歩が、自分のPDEを完成させることなのだ。Cursor + Roo-Codeが示してくれた新しい開発体験は、確かに未来の一つの形だ。しかし、それが唯一の答えではない。私たちには、自分自身の開発哲学に基づいて、自分だけの環境を構築する自由がある。「いいえ、Neovimはもっと強くなれます」—この言葉は、単なる願望ではない。それは、PDEという哲学を持つ私たちvimmerの確信なのだ。そして今、Claude Codeの登場により、私はついに二重生活から解放される。もうクライアントワークでCursor、個人でNeovimという使い分けをする必要はない。私のPDEが、すべての開発シーンで通用する強さを手に入れたのだから。そして、PDEの構築とは、一人で剣の丘で鉄を鍛つような営みだ。誰かが用意した剣ではなく、自分の手で打ち、自分の手で研ぎ、自分だけの刃を作り上げる。その過程こそが、私たちを真の開発者にするのかもしれない。この記事を書いている間、私はWarpターミナル上でNeovimとClaude Codeを行き来している。前回のavante.nvim導入から数ヶ月、そして Claude Code導入から1週間。私のPDEは確実に進化した。Lazy.nvimの設定ファイルは公開しているので、興味があれば参考にしてほしい。「Terminal Velocity」を「ターミナルベロシティ」とカタカナ表記したのは、この概念の持つ物理学的な含意—終端速度、つまり最高効率—を日本語でも感じてもらいたかったからだ。「Cursor + Roo-Codeのサブスクリプションを払い続けるか、vimの学習コストを払うか」—これは単なる経済的判断ではない。私たちが開発という行為にどう向き合うか、そしてPDEという哲学をどこまで追求するかという、実存的な選択なのかもしれない。6ヶ月のCursor + Roo-Code体験は本当に素晴らしかった。特にRoo-Codeが示してくれた「開発体験の違い」は、私の開発観を根本から変えた。もしあなたがまだ試していないなら、一度は体験する価値がある。その上で、自分にとっての最適な開発環境を選ぶべきだ。私にとって、それはPDEとしてのNeovimだった。この二重生活は疲れるものだった。.vimrcと.vscode/settings.jsonを行き来し、キーバインドの違いに戸惑い、どちらが本当の自分なのか分からなくなることもあった。しかし、その経験があったからこそ、今の決断に至ることができた。あなたも、vimmer村への帰郷を考えてみてはどうだろうか。Claude Codeという新しい仲間と共に、自分だけのPDEを完成させるために。VimConf 2025 Smallにも行こうかな…。今度こそ、胸を張って「私はvimmerです(え、Neovim ですよね？)」と言えるように。vimconf.org実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所Amazon

Claude Code を利用しようと思っているのでvimmer が住む村に帰ろうと思います。

はじめに生成AIが普及して、プログラミングの世界に「バイブコーディング（Vibe Coding）」という面白い言葉が生まれています。なんとなくの感覚や「バイブ(雰囲気)」に頼りながら、AIとやり取りしてコードを作るこの方法は、従来のプログラミングとは全く違うアプローチです。www.gitpod.iolearning.oreilly.com一方で、確率論の世界には「多腕バンディット問題」という古典的な問題があります。限られた時間の中で、どの選択肢が一番良い結果をくれるか分からない状況で、どうやって最良の選択をするか—という問題です。この二つ、一見全く関係なさそうですが、よく観察してみると驚くほど似ています。私たちがAIに色々なプロンプトを試している行動は、実は多腕バンディット問題を解いているのと同じようなことをしているのです。本稿では、この意外な共通点を深く探りながら、日常的なバイブコーディングの中に隠れている、洗練された認知メカニズムの正体に迫ってみたいと思います。注：筆者は多腕バンディット問題の専門家ではないため、解釈に誤りがある可能性があります。あくまで思考実験として読んでいただければと思います。バイブコーディングという新しい認知活動バイブコーディングをしている時、私たちは無意識に以下のようなことをしています：「こういう書き方でプロンプトを書いてみよう」「前回これでうまくいったから、今回も同じパターンでやってみよう」「なんか今日は調子悪いな、違うアプローチを試してみるか」「この例を見せた方が良いコードが出そうだ」興味深いのは、これらの行動が極めて自然に、まるで本能のように現れることです。特別な訓練を受けたわけでもないのに、多くの人が似たような試行錯誤のパターンを示します。www.businessinsider.com多腕バンディット問題多腕バンディット問題を簡単に説明すると：状況： カジノに複数のスロットマシンがあります。それぞれ当たりやすさが違いますが、どれが一番当たりやすいかは分かりません。目標： 限られた時間で、できるだけ多くの当たりを出したい。ジレンマ： 新しいマシンを試して情報を集める（探索）べきか、今まで当たりが多かったマシンをずっと使う（活用）べきか？この「探索と活用のトレードオフ」は、実は生物の進化から人間の日常生活まで、あらゆる場面に現れる根本的な意思決定パターンです。新しいレストランを試すか、お気に入りの店に行くか。新しい本を読むか、好きな作家の作品を読み返すか。私たちは常にこのジレンマと向き合っています。バンディット問題の理論とアルゴリズム (機械学習プロフェッショナルシリーズ)作者:本多淳也,中村篤祥講談社Amazonバイブコーディングをほぼスロットマシンなので...バイブコーディングを多腕バンディット問題として見たとき、その対応関係は驚くほど明確です。「スロットマシン」= プロンプトのパターン「詳しく説明してからコードを書いて」「具体例を示してから実装して」「ステップバイステップで教えて」「エラーハンドリングも含めて書いて」「当たり」= 期待する品質のコードが生成される「探索と活用のジレンマ」= 新しいプロンプト戦略を試すか、慣れ親しんだ方法を使うかしかも、この対応関係は表面的なものではありません。行動パターンの時間的変化、学習曲線、意思決定の心理的メカニズムまで、驚くほど一致しているのです。学習段階の自然な進化初心者期：無制限探索の混沌プログラミングを始めたばかりの人がAIを使う時は、まさに「片っ端から試してみる」状態です。成功率は低いものの、各プロンプトパターンがどれくらい有効かを肌感覚で学習しています。これは多腕バンディット問題における「純粋探索フェーズ」に相当します。中級者期：偏った活用の安定ある程度経験を積むと、「この書き方はいつもうまくいく」という黄金パターンを発見し、それに依存するようになります。これは効率的ですが、より良い戦略を見逃すリスクもはらんでいます。多腕バンディット問題で言う「早期収束の罠」です。上級者期：動的バランスの芸術経験豊富な人は、状況に応じて探索と活用のバランスを直感的に調整します。新しいモデルが出れば探索モードに戻り、安定したタスクでは効率的なパターンを活用します。これは最も洗練された多腕バンディット戦略と言えるでしょう。この自然な進化過程は、特別な理論を学ばなくても、人間が本能的に最適化アルゴリズムを身につけることを示しています。コンテキストによる戦略の分化興味深いことに、プログラミング言語やAIモデルが変わると、最適なプロンプト戦略も変化します。Pythonでうまくいくアプローチが、C++では効果的でない。GPT-4で成功した方法が、Claude では通用しない。これは多腕バンディット問題における「コンテキスト付きバンディット」の典型例です。同じ「腕」（プロンプトパターン）でも、文脈によって期待報酬が変わるのです。熟練したエンジニアは、この文脈の切り替えを無意識に行います。言語を変えると同時に、プロンプト戦略も自動的に調整される。これは、人間の適応的学習能力の驚くべき柔軟性を物語っています。「報酬」の多次元性と測定の難しさバイブコーディングにおける「報酬」は、多腕バンディット問題の古典的な設定よりもはるかに複雑です。即座に測定できる報酬コンパイルが通る期待した動作をする実行時間が短い長期的な報酬コードの可読性保守のしやすさチーム開発での再利用性主観的な報酬「美しい」コード学習になるコード創意工夫のあるコードこの多次元的な報酬構造が、バイブコーディングを単純な最適化問題以上の、芸術的な活動にしているのかもしれません。自動テストが変革する「報酬関数」ここで自動テストの存在が、バイブコーディングの性質を根本的に変えることに注目したいと思います。テストがない状況では、報酬の測定は主観的で曖昧です。「なんとなく動いているから良いコード」という判断は、多腕バンディット問題で言う「ノイズの多い報酬シグナル」です。一方、自動テストがある場合、報酬は明確で客観的になります。「全テストが通る」は0か1かの明確な成功指標です。これにより、どのプロンプト戦略が本当に効果的かを正確に学習できるようになります。この変化は単なる測定精度の向上以上の意味を持ちます。報酬関数の明確化により、学習アルゴリズムそのものが高度化するのです。syu-m-5151.hatenablog.comプロンプトエンジニアリングという「期待値制御」プロンプトエンジニアリングを多腕バンディット問題の視点で見ると、これは「各腕の期待報酬を高める技術」と解釈できます。曖昧なプロンプト「ログイン機能を作って」は、期待報酬の分散が大きい「腕」です。うまくいく時もあれば、全く期待外れの結果になることもある。一方、詳細で構造化されたプロンプトは、期待報酬の平均値を高め、分散を小さくします。これは多腕バンディット問題において、明らかに優位な「腕」です。興味深いのは、多くの人がプロンプトエンジニアリングの重要性を、理論を知らずとも実感していることです。これは、人間が直感的に「期待値と分散の最適化」を理解していることを示唆しています。チーム協働における「集合知のバンディット」個人でのバイブコーディングから、チームでの協働に視点を移すと、さらに興味深い現象が見えてきます。複数のエンジニアが異なる「腕」を並行して探索し、成果を共有する。これは「協調型バンディット」と呼ばれる高度な問題設定です。全員が同じ試行錯誤を繰り返す無駄を避け、チーム全体として効率的に最適解に近づいていきます。「このプロンプトパターンが効果的だった」「このアプローチは避けた方がいい」こうした情報共有は、個人の学習速度を遥かに超える集合的な最適化を可能にします。人間が本能的に行う知識共有行動が、実は数学的に最適な協調戦略だったのです。AIモデル進化への適応：非定常環境での生存戦略AIモデルの頻繁なアップデートは、バイブコーディングに非定常性という新たな次元を加えます。昨日まで最適だった戦略が、新しいモデルでは全く効果がない。これは生物の進化圧にも似た、動的な環境変化です。この変化に対して、経験豊富なエンジニアは見事な適応を見せます。新しいモデルが出ると、自動的に「探索モード」に切り替わる。過去の成功体験にとらわれず、新たな最適解を求めて試行錯誤を始める。この柔軟性は、多腕バンディット問題の理論が想定する以上の高度な適応能力です。環境の変化を察知し、学習戦略そのものを動的に調整する—これは人間の認知能力の真骨頂と言えるでしょう。「バイブ」の正体：統計的直感の結晶「バイブ」や「勘」と呼ばれる現象の正体を、多腕バンディット問題の枠組みで考えてみると、驚くべき洞察が得られます。経験豊富なエンジニアが「なんとなくこのアプローチが良さそう」と感じる時、それは過去の膨大な試行錯誤から蓄積された統計的パターンの内在化です。意識的には覚えていない微細な成功・失敗の記憶が、直感的判断として表面化している。これは、Thompson Samplingという高度なアルゴリズムと本質的に同じメカニズムです。過去の経験から各戦略の成功確率分布を学習し、その分布に基づいて確率的に選択を行う。完全に論理的でもなく、完全にランダムでもない、絶妙なバランスの意思決定です。「バイブ」は非科学的なものどころか、むしろ最先端の確率的アルゴリズムを人間が自然に実装している証拠なのです。中毒性の数学的説明バイブコーディングに多くの人が「ハマる」理由も、多腕バンディット問題の枠組みで説明できます。新しいプロンプトを試すたびに得られる「うまくいくかもしれない」という期待感。実際に良いコードが生成された時の達成感。これらは、不確実性の中で最適解を探索する過程で得られる本能的な報酬です。人間の脳は、探索と活用のバランスを取る活動に対して、進化的に報酬を与えるよう設計されています。バイブコーディングがこの古い報酬系を刺激するからこそ、多くの人が夢中になるのでしょう。なぜこの類似性が存在するのかここで根本的な問いに向き合ってみましょう。なぜバイブコーディングと多腕バンディット問題は、これほどまでに似ているのでしょうか？一つの仮説は、人間の学習と意思決定の根底にある共通のメカニズムです。不確実な環境で最適な選択を見つけるという課題は、人類が何十万年もの間直面してきた生存問題でした。どの狩場が豊富な獲物をもたらすか。どの植物が安全で栄養価が高いか。多腕バンディット問題は、この根本的な生存戦略を数学的に抽象化したものです。そして、バイブコーディングは、この古い学習メカニズムが新しい技術的環境で発現したものなのかもしれません。イプシロン-グリーディ戦略としての日常多くのエンジニアが無意識に実践している行動パターンを詳しく観察すると、「イプシロン-グリーディ戦略」との類似性が見えてきます：大部分の時間（90%）: 今まで最も成功率の高かった方法を使う（活用）少しの時間（10%）: 新しい方法を試してみる（探索）「いつものパターンでやってみよう。あ、でもたまには違うアプローチも試してみるか」この何気ない意思決定が、実は数学的に洗練された最適化戦略だというのは、驚くべき発見です。UCB的思考の高次元化より洗練された判断をする人は、UCB（Upper Confidence Bound）アルゴリズムに似た思考を示します：「このプロンプトは過去に良い結果を出したけど、まだ試行回数が少ないから、もう少し試してみる価値がある」これは、平均的な成功率だけでなく、「不確実性」も考慮した意思決定です。試行回数が少ない選択肢に対して「まだ可能性がある」という判断を下す。この高次な推論を、多くの人が自然に行っているのです。認知バイアスとしての「過度な活用」一方で、バイブコーディングには多腕バンディット問題と同様の落とし穴もあります。早期収束の罠: 最初に見つけた成功パターンに固執し、より良い方法を探索しなくなる。確証バイアス: 自分のお気に入りの方法がうまくいった事例ばかりを記憶し、失敗例を忘れてしまう。環境変化への適応遅れ: 新しいAIモデルが出ても、古い戦略に固執し続ける。これらの認知バイアスは、多腕バンディット問題における「準最適解への収束」と本質的に同じ現象です。人間の学習メカニズムの限界が、両方の文脈で同様に現れているのです。思考実験から見えてくることこの思考実験から得られる洞察を、整理してみましょう。第一に、私たちが日常的に行っている「試行錯誤」は思っているより合理的だということです。「なんとなく」でプロンプトを選んでいるように見えて、実は過去の経験から学習した効率的な戦略を使っているのです。第二に、自動テストやプロンプトエンジニアリングが効果的な理由が、多腕バンディット問題の観点から説明できることです。これは単なる「ベストプラクティス」ではなく、学習効率を上げる合理的な手法だったのです。第三に、チームでのAI活用が個人より効果的な理由も明確になります。みんなで情報共有することで、効率的に最適解を見つけられる。これは感覚的に分かっていたことですが、理論的な裏付けがあったということです。エンジニアとしての実感実際にバイブコーディングをしている身として、この類似性には「なるほど、そういうことか」という納得感があります。新しいプロジェクトを始める時の「色々試してみる」段階、ある程度慣れてきて「いつものパターン」を使うようになる段階、そして新しいAIモデルが出ると再び「探索モード」に戻る段階。この流れは、多くのエンジニアが体験していることでしょう。特に興味深いのは、「なんか今日は調子悪いな」と感じて戦略を変える時の判断です。これも、実は環境の変化を察知した合理的な適応行動だった可能性があります。おわりにこの思考実験の面白さは、日頃「感覚的」だと思っていた行動に、実は理論的な構造があったという発見にあります。「バイブ」と呼んでいた直感は、決してランダムな当て推量ではありませんでした。それは、過去の大量の試行錯誤から学習した、効率的な意思決定メカニズムのように思えます。私たちがAIに向かって何気なくプロンプトを打っている時、実は無意識のうちに確率的な最適化を行っている。理論を知らなくても、効果的な学習戦略を実践している。この発見は、バイブコーディングをただの「なんとなくのコーディング」から、理論に裏打ちされた合理的なアプローチとして捉え直すきっかけを与えてくれます。最終的に、この思考実験が示しているのは、私たちエンジニアが思っているより賢く、効率的に学習し、適応しているということです。それは決して特別なことではなく、人間が持つ自然な学習能力の現れなのかもしれません。

【思考実験】バイブコーディング(Vibe coding)と多腕バンディット問題 - 選択の最適化と報酬の探索

これから伸びるエンジニア職とは？  - AI時代に市場価値を高めるキャリア戦略 @エンジニア業界セミナー in 会津大学

ブログ記事評価プロンプト (0.0-5.0)を作成しました。

RustのWebアプリケーションにオブザーバビリティを実装するインフラエンジニアのための入門ガイド

本日、Forkwell さんに悪ふざけに付き合ってもらってイベントやりました。ありがとうございます。「転職したらMCPサーバーだった件」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 転職したらMCPサーバーだった件- 公式URL: https://forkwell.connpass.com/event/354289/- ハッシュタグ: https://x.com/search?q=%23Forkwell_MCP&f=live- 参考資料①: https://speakerdeck.com/nwiizo/kokohamcpnoye-ming-kemae- 参考資料②: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057- 参考資料③: https://speakerdeck.com/superbrothers/that-time-i-changed-jobs-as-a-kubernetes

転職したらMCPサーバーだった件

中学17年生

MCP-Useとは何か？MCP-Use (Model Context Protocol - Use) は、LLM（大規模言語モデル）とMCPサーバーの間の橋渡しをするPythonライブラリです。このライブラリにより、OpenAI、Anthropic、Groqなど様々なLLMプロバイダーのモデルに、Webブラウジングやファイル操作といった外部ツールへのアクセス権を付与できます。github.com環境構築：uvの活用今回はRustベースの高速パッケージマネージャーuvを使って環境を構築します。docs.astral.sh# 仮想環境を作成uv venv# 仮想環境をアクティベートsource .venv/bin/activate.fish  # fishシェル使用時# 必要なパッケージをインストールuv pip install "mcp-use[dev,anthropic,openai,search]"uv pip install fastembeduv pip install python-dotenv langchain-openai従来のpipと比較してuvは大幅に高速で、特に複雑な依存関係を持つプロジェクトではその差が顕著です。MCP-Useはさまざまな依存関係を持つため、uvの使用が特に有効です。MCP-Useの基本構造MCP-Useの中核は以下のクラスから構成されています：MCPClient: 設定ファイルからMCPサーバーへの接続を管理MCPAgent: LLMとMCPサーバーを組み合わせてタスクを実行各種アダプター: LLMプロバイダーとMCPサーバー間の変換処理実装例：ウェブ情報取得エージェント今回はMCP-Useを使って、特定のWebサイトから情報を抽出するエージェントを構築します。import asyncioimport osfrom dotenv import load_dotenvfrom langchain_openai import ChatOpenAIfrom mcp_use import MCPAgent, MCPClientasync def main():    # 環境変数を読み込み    load_dotenv()    # 設定ファイルからMCPClientを作成    client = MCPClient.from_config_file(        os.path.join(os.path.dirname(__file__), "browser_mcp.json")    )    # LLMを初期化    llm = ChatOpenAI(model="gpt-4o")        # エージェントを作成    agent = MCPAgent(llm=llm, client=client, max_steps=30)    # クエリを実行    result = await agent.run(        "3-shake.com にアクセスして株式会社スリーシェイクのCEOのxアカウントを教えて下さい",        max_steps=30,    )    print(f"\nResult: {result}")if __name__ == "__main__":    asyncio.run(main())以下、各部分の詳細を解説します。1. MCPClient初期化とその内部構造client = MCPClient.from_config_file(    os.path.join(os.path.dirname(__file__), "browser_mcp.json"))MCPClientクラスはMCPサーバーへの接続を管理します。from_config_fileメソッドで設定ファイルから構成を読み込みます。設定ファイルbrowser_mcp.jsonの中身は以下のようになっています：{  "mcpServers": {    "playwright": {      "command": "npx",      "args": ["@playwright/mcp@latest"],      "env": {        "DISPLAY": ":1"      }    }  }}この設定は、PlaywrightをMCPサーバーとして使用することを指定しています。MCPClientはこの設定を読み込み、以下の処理を実行します：設定に基づいて適切なコネクタ（この場合はStdioConnector）を作成コネクタを使ってPlaywright MCPサーバーとの通信チャネルを確立初期化処理を実行し、利用可能なツールの一覧を取得内部的には、MCP-Useは非同期処理を多用しており、asyncioを活用した効率的な通信を実現しています。2. LLMの初期化と統合llm = ChatOpenAI(model="gpt-4o")MCP-UseはLangChainとシームレスに統合されており、様々なLLMプロバイダーのモデルを使用できます。今回はOpenAIのGPT-4oを使用していますが、以下のように簡単に切り替えることも可能です：# Anthropicのモデルを使用する場合from langchain_anthropic import ChatAnthropicllm = ChatAnthropic(model="claude-3-5-sonnet-20240620")# Groqのモデルを使用する場合from langchain_groq import ChatGroqllm = ChatGroq(model="llama3-8b-8192")MCP-Useの内部では、LangChainAdapterクラスがLLMとMCPサーバー間の変換処理を担当し、ツールの記述をLLMが理解できる形式に変換しています。3. MCPAgentの作成と実行agent = MCPAgent(llm=llm, client=client, max_steps=30)MCPAgentクラスは、LLMとMCPクライアントを組み合わせてタスクを実行するための中核コンポーネントです。主なパラメータは：llm: 使用するLLMモデルclient: MCPクライアントインスタンスmax_steps: エージェントが実行できる最大ステップ数max_stepsパラメータは特に重要で、タスクの複雑さに応じて適切な値を設定する必要があります：- 単純な情報検索: 5-10ステップ- 複数ページの探索: 15-20ステップ- 複雑な操作: 25-30ステップ4. タスク実行の内部処理result = await agent.run(    "3-shake.com にアクセスして株式会社スリーシェイクのCEOのxアカウントを教えて下さい",    max_steps=30,)agent.run()メソッドが呼び出されると、以下の処理が実行されます：指定されたクエリをLLMに送信し、実行プランを生成LLMが適切なツールを選択し、その実行をリクエストMCPクライアントがツールのリクエストをMCPサーバーに転送MCPサーバーがツールを実行し、結果を返す結果をLLMに返し、次のステップを決定最終的な回答が生成されるまで、ステップ2-5を繰り返す内部的には、この処理はMCPAgent.run()メソッド内の_agent_executor._atake_next_step()メソッドで実装されています。

MCP-Use を使っていきます

soudai.hatenablog.comそーだいさんの「頑張らなくてもいいから、成果で応えよう」という記事を読み、「頑張ること」について改めて考えさせられた。「頑張る」の幻想と私たちの関係日本文化においてというか自分が育ってきた環境では「頑張る」という言葉には特別な地位があった。子どもの頃から「頑張れ」と叱咤激励され、「頑張ります」と答えることが社会的な美徳や道徳的な行いとされてきた。多くの場面で「頑張ります」と宣言するだけで、一時的に評価されるか、少なくとも批判を免れる魔法のような効果を持っている。しかし、この「頑張る」という概念を現場で聞くと自分も奇妙だと感じる。専門的な仕事に対する報酬は、結局のところ労力の投入量ではなく、生み出された価値に対して支払われるものだ。高額な費用を支払う依頼者が期待するのは、徹夜して疲れた顔をすることではなく、問題解決の価値を提供することだろう。「努力」と「成果」の非対称性ビジネスの世界では、しばしば「依頼者と受託者の利害不一致」が問題になる。経済学では「エージェンシー問題」と呼ばれるこの現象は、仕事を頼む側と引き受ける側の間に生じる情報や目的の不均衡から発生する。例えば、受託者は「一生懸命頑張っている」姿を見せることで、依頼者に「価値ある仕事」をしているという印象を与えられる。しかし、依頼者が本当に必要としているのは、その問題が解決されることであって、受託者の頑張りそのものではない。受託者が自分の興味や都合を優先して「頑張る」ことで、依頼者が必要としない複雑な作業に時間を費やすこともある。これもエージェンシー問題の一例だといえる。このとき「頑張っています」という言葉は、実は成果を出せない責任から自分を守る防御機制になっていることがある。「精一杯やりました」という免罪符を先に用意しているようなものだ。プロフェッショナルは、このような情報の非対称性を利用するのではなく、依頼者の本当のニーズを理解し、それに応える成果を出すことで信頼を勝ち取る。ja.wikipedia.org個人の「頑張り」と本質的価値では個人として「頑張る」ことに価値はないのだろうか？ここで重要なのは、「頑張る」という言葉に対する冷笑的な態度と、本質的な「頑張り」の価値を区別することだ。SNSやぎむきょー時代は「頑張り」を馬鹿にする風潮も見られるが、それは本来の議論とは異なる。正直に告白すると、学生時代の私自身も「頑張っている人」を冷笑していた時期があった。努力している人を見て「あんなに必死になって」と馬鹿にしていたのは、おそらく自分の怠惰や無為を正当化するための防衛機制だったのだろう。SNSで見られる「頑張り」への皮肉や揶揄も、多くの場合、同様の心理から生まれていると思われる。しかし、本稿で論じているのはそうした冷笑とは全く異なる。単なる努力否定論ではなく、むしろ「頑張り」の本質と方向性についての考察であり、努力そのものの価値を問い直すものである。ここで大切なのは、無意味な労力を省く知恵と、本当に必要な部分への集中という、より高度な「頑張り」の形だ。もちろん、個人の成果、成長や技術向上のためには「頑張り」が必要だ。しかし、その「頑張り」は闇雲に時間や労力を投入することではなく、最も効果的な方向に集中させることが重要だろう。そして、この「方向性を見極める努力」こそが、実は最も価値のある「頑張り」なのだ。優れた個人の強みは、複雑な問題を単純化する能力にある。たとえば、長時間かけて解決できる問題を短時間で実装できれば、それはただの時間節約ではなく、将来的な労力やリスクの削減にもつながる。こうした「頑張らない工夫」のために費やす知的努力こそが、実は最も価値のある「頑張り」なのだ。つまり、見た目の労力と実質的な価値創造は必ずしも比例しないということである。何をするかを決めることと同じくらい、何をしないかを決めることが重要だ。プロフェッショナルは、あらゆることに対して「Yes」と言うのではなく、価値の低い活動には意識的に「No」と言う勇気を持っている。時間とエネルギーは有限だからこそ、本当に重要なことに集中するために、何かを捨てる決断が必要になる。この「選択する」という行為自体が、実は高度な「頑張り」を要するものだ。大企業や大規模な組織に比べて、個人や小さな組織が持つ強みの一つは、無駄な儀式的活動を省略できることにある。形式的な定例会議や不必要な報告書作成に時間を費やす代わりに、本質的な価値を生み出す活動や意思決定に集中できる自由がある。これは実は大きな競争優位性となり得る。この「本質」を見極める洞察力を養うこともまた、「頑張る」べき重要な領域なのだ。起こる可能性のあることは、いつか実際に起こる。「頑張る」という抽象的な概念から脱却するためには、具体的な仕組みを設計する思考へ転換する必要がある。努力の量よりも、その方向性と持続可能性が重要だ。問題の解決に徹夜で取り組むことを否定するわけではないが、優れたエンジニアは、より本質的には問題が再発しないような仕組みの構築に力を注ぐ。例えば、作業を手動で何度も「頑張る」のではなく、自動化の仕組みを整備する。毎回の業務で時間をかけて「頑張る」のではなく、再利用可能なテンプレートやガイドラインを整備する。問題が起きるたびに対処法を「頑張って」思い出すのではなく、解決策を体系化したマニュアルを作成する。「人間が頑張る」システムから「仕組みが支える」システムへの転換が、価値を生み出す。とにかく仕組み化――人の上に立ち続けるための思考法作者:安藤 広大ダイヤモンド社Amazon360度評価の落とし穴多くの企業で導入されている360度評価は、一見公平に見えるが、実はこの「頑張り」の価値観を強化してしまう側面がある。同僚や部下からの評価では、実際の成果や生み出した価値よりも「頑張っているように見える」人が高く評価される傾向がある。例えば、遅くまでオフィスに残っている人、頻繁にメッセージや進捗報告を送る人、会議で積極的に発言する人、多くのタスクを抱えて「忙しそう」に見える人は「熱心に働いている」という印象を与えやすい。しかし、こうした「頑張っている姿」は、必ずしも組織や顧客にとっての価値創造に結びついているとは限らない。むしろ静かに効率的に成果を出している人が、「あの人は楽をしている」と誤解されることすらある。見た目の「頑張り」で評価される環境は、本来の価値創造を歪める要因となる。この歪みが組織全体の非効率を生み出し、真に重要な成果よりも「頑張っている姿勢」が優先される文化を強化してしまうのだ。「頑張らない」の誤解を解く「頑張らない」という言葉を聞くと、「怠けている」「熱意がない」という印象を持つ人も多いだろう。しかし本質は「無駄な労力を費やさない」ということだ。優れたプロフェッショナルとは、最小限の労力で最大限の成果を出す人のことであり、闇雲に時間や労力を投入する人のことではない。例えば、ソフトウェア開発なら、少ない時間で短く洗練されたコードで同じ機能を実現できる人のほうが、多くの時間を使って冗長で複雑なコードを書く人よりも高い評価を受けるべきだ。これは他の職種でも同様だ。営業担当者が100件の見込み客に電話するよりも、10件の有望な見込み客に集中して高い成約率を出す方が価値がある。デザイナーが何十もの案を作るよりも、ユーザーの本質的なニーズを捉えた1つの優れた案を作る方が価値がある。マネージャーが長時間のミーティングを主催するよりも、短時間で明確な意思決定と方向性を示せる方が価値がある。限られた時間とエネルギーをどう使うかが、プロフェッショナルの条件だ。多くの場合、「頑張らない」と見られる人ほど、実は効率的な方法論や再利用可能な仕組みを作り出すことで、生産性を高めている。NINE LIES ABOUT WORK 仕事に関する9つの嘘作者:マーカス・バッキンガム,アシュリー・グッドールサンマーク出版Amazon「頑張り」の再定義個人として「頑張る」ことを完全に否定するわけではない。むしろ、その意味を再定義する必要がある。「頑張る」とは、ただ長時間働くことや疲れ果てることではなく、最も効率的な方法を見つけるために思考し、試行錯誤することかもしれない。「頑張ります」と言う代わりに、「この売上低下の問題を解決するために、まずデータを分析し、次週までに具体的な改善策を提案します」のように具体的なコミットメントを示すほうが建設的だ。抽象的な精神論ではなく、具体的で測定可能なアクションにフォーカスすることで、本当の意味での価値が生まれる。これは実は「頑張らない」ように見えて、もっとも「頑張るべき」部分かもしれない。人生は、運よりも実力よりも「勘違いさせる力」で決まっている作者:ふろむだダイヤモンド社Amazon「頑張ってるので安心」からの解放「頑張っているので安心してください」という言葉の裏には、「結果が出なくても責めないでください」という暗黙の訴えがある場合が多い。しかし、このような思考パターンからは脱却する必要がある。自分自身に対しては、「これをやって、この結果を出します」という具体的なコミットメントへと転換することが、ちゃんとした価値を生み出す第一歩だろう。ただし、この考え方を他者に向けて適用する際には注意が必要だ。相手の背景や文脈、置かれた状況を完全に理解できているわけではない。「頑張り」ではなく「成果」を求めることは理にかなっているが、相手の環境や制約条件、直面している課題の複雑さを把握せずに一方的に求めることは、非常に危険である。むしろ、他者との関係においては、まず相手の状況を理解し、適切なサポートや環境づくりを考えることが先決だ。また、自分が生み出した「価値」が適切に評価されていないと感じるなら、それは単に評価システムの問題ではなく、組織や上長、周囲の人々との間に「価値基準の違い」が存在している可能性がある。自分が重視する価値と、組織が求める価値が異なっていれば、どれだけ成果を出しても評価されにくい。このミスマッチに気づくことは、自分のキャリアを考える上で非常に重要なポイントになる。自分の価値観に合った環境を選ぶか、あるいは組織の価値基準を理解した上で自分の貢献の方向性を調整するか、選択が必要になるだろう。最終的に評価されるのは「頑張った過程」よりも「生み出した価値」だ。この現実を受け入れ、「頑張っているので安心」という幻想から脱することが、個人としての成長への本質的なステップなのかもしれない。もうそろそろ、30歳になるのでそういう事も考えます。追記: "本質的な価値"と"価値基準の違い"本稿では「本質的な価値」と「価値基準の違い」という概念を提示してきたが、果たしてこれらは矛盾しないのだろうか。実際のところ、絶対的な「本質的価値」など存在するのだろうか。冷静に考えれば、所謂誰かが言っている「本質的価値」とは常に文脈依存であり、普遍的なものではない。我々が価値と呼ぶものは、結局のところ特定の社会や組織、個人の視点から定義されたものに過ぎない。人間として普遍的な「本質的価値」を探すならば、それは生命体としての存続と尊厳、心身の調和、そして精神的充足感以外には基本的に見当たらないのではないだろうか。人間という生命体にとって生物学的な生存と精神的な均衡が確かに基礎的な価値だが、それを超えた「価値」は全て社会的に構築されたものだ。企業が求める「価値」は利益最大化かもしれないし、NPOが重視する「価値」は社会貢献かもしれない。個人が大切にする「価値」は自己実現かもしれないし、家族との時間かもしれない。つまり、「本質的価値」を絶対視することこそが、新たな幻想を生み出す危険性をはらんでいる。ある組織で評価される「価値」が、別の組織では全く評価されないこともあるのだ。重要なのは、自分が属する環境で何が「価値」とされているかを正確に理解し、それが自分の信じる「価値」と一致するかを見極めることだろう。一致しない場合、二つの選択肢がある。一つは環境を変えること、もう一つは自分の貢献の方向性を調整することだ。どちらが正しいというわけではなく、各自の状況や志向に応じた選択が必要になる。結局のところ、「頑張る」という曖昧な概念から脱却し、具体的な成果や貢献にフォーカスすることは重要だが、その「成果」や「貢献」自体も絶対的なものではなく、常に特定の文脈の中で評価されるものだということを忘れてはならない。生存と心身の調和を超えれば、あらゆる「価値」は相対的なものであり、その点を認識することこそが、現実的なキャリア構築や人間関係の基盤となるのではないだろうか。あと、「頑張ってるので安心」から脱してもそれでも頑張るしかないのが凡人の辛いところ。

「頑張ってるので安心」から脱する

 20代最後の一週間を生きるエンジニア、あるいは30歳の扉の前でうろたえる男の独白

はじめにMacBookでRustを使ってスクリーンショットを撮る方法について紹介します。この記事では、次の2つのアプローチを解説します：OpenCVを活用する方法 — 画像処理の多彩な機能を利用外部ライブラリに依存しない方法 — シンプルながら効果的それぞれのアプローチには利点と課題があります。詳細なコード例を交えながら、最終的にはSlackウィンドウを自動検出する実用的なテクニックまでご紹介します。最近ではマルチモーダルAIの発展により、AIシステムもスクリーンショットの取得と分析を行うことが増えています。生成AIが画面の視覚情報を理解し、より的確な支援を提供するためには、高品質なスクリーンショット機能が不可欠です。本記事で紹介する技術は、そうしたAIシステムの視覚的入力にも応用できるでしょう。目次はじめに目次使用するクレートmacOS環境のセットアップOpenCVのインストール（OpenCVアプローチの場合）LLVMとClangのインストール（OpenCVアプローチの場合）環境変数の設定（OpenCVアプローチの場合）XCapのみのセットアップ（シンプルアプローチ）Cargo.tomlの設定OpenCVアプローチの場合OpenCVに依存しないアプローチの場合OpenCVアプローチ：基本的なスクリーンショット処理MacOSでの画像保存の問題と解決策OpenCVに依存しないアプローチ簡易な画像解析を実装する実用例：Slackスクリーンショットモニタートラブルシューティング1. libclang.dylibが見つからない場合2. OpenCVのライブラリが見つからない場合3. リンクエラー: imwrite, imencodeなどの関数が見つからないまとめ参考リンク使用するクレート今回使用する主なクレートは以下の通りです：xcap - Rust製のクロスプラットフォーム対応スクリーンキャプチャライブラリopencv - OpenCVのRustバインディング（OpenCVアプローチのみ）macOS環境のセットアップMacBookでスクリーンショット処理を行うための環境構築について解説します。OpenCVのインストール（OpenCVアプローチの場合）Homebrewを使って簡単にOpenCVをインストールできます：brew install opencvLLVMとClangのインストール（OpenCVアプローチの場合）opencv-rustクレートはバインディング生成にlibclangを使用しています：brew install llvm環境変数の設定（OpenCVアプローチの場合）OpenCVとLLVMを正しく検出するために、以下の環境変数を設定します。これらの設定は.zshrcや.bash_profileに追加しておくと便利です：# OpenCV設定export OPENCV_LINK_LIBS="opencv_core,opencv_imgproc,opencv_highgui,opencv_videoio"export OPENCV_LINK_PATHS="/opt/homebrew/lib"  # Apple Siliconの場合export OPENCV_INCLUDE_PATHS="/opt/homebrew/include/opencv4"# LLVM/Clang設定export LIBCLANG_PATH=$(brew --prefix llvm)/libexport DYLD_LIBRARY_PATH=$(brew --prefix llvm)/lib:$DYLD_LIBRARY_PATH注意: パスはApple Siliconモデルの場合です。Intel Macでは異なる場合があります。brew --prefix opencv コマンドで確認できます。XCapのみのセットアップ（シンプルアプローチ）OpenCVを使わない場合は、xcapクレートだけをインストールします：cargo add xcapCargo.tomlの設定プロジェクトのCargo.tomlファイルは以下のようになります：OpenCVアプローチの場合[dependencies]xcap = "0.0.4"opencv = { version = "0.94.4", features = ["clang-runtime"] }OpenCVに依存しないアプローチの場合[dependencies]xcap = "0.0.4"OpenCVアプローチ：基本的なスクリーンショット処理OpenCVを使ったスクリーンショット処理の基本的なコードを紹介します：use std::time::Instant;use xcap::Monitor;use opencv::prelude::*;use opencv::core::{Mat, Size, CV_8UC4};use opencv::imgproc;use opencv::highgui;fn main() -> Result<(), Box<dyn std::error::Error>> {    // OpenCVのウィンドウを作成    highgui::named_window("Screenshot", highgui::WINDOW_AUTOSIZE)?;    highgui::named_window("Processed", highgui::WINDOW_AUTOSIZE)?;    println!("Press 'q' to exit");    // メインループ    loop {        let start = Instant::now();        // プライマリモニターを取得        let monitors = Monitor::all()?;        let primary_monitor = monitors.iter().find(|m| m.is_primary().unwrap_or(false))            .unwrap_or(&monitors[0]);        // スクリーンショットを撮影        let image = primary_monitor.capture_image()?;        let width = image.width() as i32;        let height = image.height() as i32;                // ピクセルデータを取得        let raw_pixels = image.as_raw();        // OpenCVのMat形式に変換        let mat = unsafe {            let mut mat = Mat::new_size(Size::new(width, height), CV_8UC4)?;            let mat_data = mat.data_mut();            std::ptr::copy_nonoverlapping(                raw_pixels.as_ptr(),                mat_data,                (width * height * 4) as usize            );            mat        };        // 元のスクリーンショットを表示        highgui::imshow("Screenshot", &mat)?;        // 画像処理の例: グレースケール変換        let mut gray = Mat::default();        imgproc::cvt_color(            &mat,             &mut gray,             imgproc::COLOR_BGRA2GRAY,             0,             opencv::core::AlgorithmHint::ALGO_HINT_DEFAULT        )?;        // エッジ検出の例        let mut edges = Mat::default();        imgproc::canny(&gray, &mut edges, 100.0, 200.0, 3, false)?;        // 処理した画像を表示        highgui::imshow("Processed", &edges)?;        // 処理時間を表示        println!("処理時間: {:?}", start.elapsed());        // キー入力を待つ（10ms）        let key = highgui::wait_key(10)?;        if key == 'q' as i32 || key == 'Q' as i32 {            break;        }    }    Ok(())}このコードは以下のことを行います：XCapを使ってプライマリモニターのスクリーンショットを撮影スクリーンショットのデータをOpenCVのMat形式に変換元のスクリーンショットを表示し、グレースケール変換とエッジ検出を適用した処理結果も表示OpenCVを使う大きなメリットは、豊富な画像処理機能を利用できることです。グレースケール変換、エッジ検出、顔認識など多様な処理が可能です。MacOSでの画像保存の問題と解決策MacOSでOpenCVのimwriteやimencode関数を使用すると、リンクエラーが発生することがあります。以下のカスタム関数を使用して回避できます：// MacOS環境のためのOpenCVラッパー関数fn save_image(filename: &str, img: &Mat) -> Result<bool, Box<dyn std::error::Error>> {    // Rustのファイル操作を使用してOpenCVのMatをPNGとして保存    println!("画像を保存しています: {}", filename);        // エンコード用のベクタ    let mut buf = opencv::core::Vector::new();        // BGR形式の画像をPNGにエンコード    opencv::imgcodecs::imencode(".png", img, &mut buf, &opencv::core::Vector::new())?;        // ファイルに書き込み    fs::write(filename, buf.as_slice())?;        Ok(true)}しかし、この関数もOpenCVのバージョンやMacOSの設定によってはエラーになる場合があります。その場合は次に説明するOpenCVに依存しないアプローチを検討することをお勧めします。OpenCVに依存しないアプローチOpenCVのリンクエラーや複雑な設定を避けたい場合は、XCapクレートのみを使用したシンプルなアプローチも可能です：use std::time::Instant;use std::fs;use xcap::Monitor;fn main() -> Result<(), Box<dyn std::error::Error>> {    println!("スクリーンショットプログラムを開始しました");    println!("終了するには Ctrl+C を押してください");    // メインループ    loop {        let start = Instant::now();        // プライマリモニターを取得        let monitors = Monitor::all()?;        let primary_monitor = monitors.iter().find(|m| m.is_primary().unwrap_or(false))            .unwrap_or(&monitors[0]);        // スクリーンショットを撮影        let image = primary_monitor.capture_image()?;                // スクリーンショットを保存        let timestamp = std::time::SystemTime::now()            .duration_since(std::time::SystemTime::UNIX_EPOCH)?            .as_secs();        let filename = format!("screenshot_{}.png", timestamp);                // XCapのsaveメソッドを使用して直接保存        image.save(&filename)?;                println!("スクリーンショットを保存しました: {}", filename);        println!("処理時間: {:?}", start.elapsed());                // 適当な間隔を空ける        std::thread::sleep(std::time::Duration::from_secs(5));    }    Ok(())}このアプローチのメリットは：セットアップが格段に簡単（OpenCVやLLVMのインストールが不要）リンクエラーなどのトラブルが少ない軽量で高速一方、デメリットは：高度な画像処理機能が使えない独自の画像解析ロジックを実装する必要がある簡易な画像解析を実装するOpenCVを使わずに簡易な画像解析を行う例として、特定の色を検出するコードを示します：// 簡易な色検出機能fn detect_color(rgba_data: &[u8], width: u32, height: u32) -> bool {    // 特定の色の範囲（RGB値）    let target_lower_r = 200;    let target_lower_g = 0;    let target_lower_b = 0;        let target_upper_r = 255;    let target_upper_g = 100;    let target_upper_b = 100;        let mut target_pixel_count = 0;    let total_pixels = (width * height) as usize;        // ピクセルデータを4バイトずつ処理（RGBA）    for i in (0..rgba_data.len()).step_by(4) {        if i + 2 < rgba_data.len() {            let r = rgba_data[i];            let g = rgba_data[i + 1];            let b = rgba_data[i + 2];                        // 指定した範囲内の色かどうかを判定            if r >= target_lower_r && r <= target_upper_r &&               g >= target_lower_g && g <= target_upper_g &&               b >= target_lower_b && b <= target_upper_b {                target_pixel_count += 1;            }        }    }        // 閾値: 特定の色のピクセルが一定数以上あれば検出成功    let threshold_ratio = 0.01; // 全ピクセルの1%以上    let has_enough_pixels = (target_pixel_count as f64 / total_pixels as f64) > threshold_ratio;        has_enough_pixels}このコードはRGBA値を直接処理して、指定した色範囲のピクセル数をカウントします。単純ですが、特定の色を持つUIエレメントの検出などには十分な場合があります。実用例：Slackスクリーンショットモニター参考的な例として、Slackウィンドウを自動検出してスクリーンショットを保存するアプリケーションを作ってみましょう。以下では、OpenCVに依存しないシンプルなバージョンを紹介します：use std::time::{Instant, Duration, SystemTime};use std::fs;use std::path::Path;use std::thread;use xcap::Monitor;// スクリーンショット撮影の設定const SCREENSHOT_INTERVAL: u64 = 5; // 5秒ごとにスクリーンショットを撮影const SAVE_PATH: &str = "slack_screenshots";// 簡易なSlackウィンドウ検出機能fn detect_slack_window(rgba_data: &[u8], width: u32, height: u32) -> bool {    // Slackの紫色の範囲（RGB値）    let purple_lower_r = 100;    let purple_lower_g = 50;    let purple_lower_b = 130;        let purple_upper_r = 170;    let purple_upper_g = 100;    let purple_upper_b = 210;        let mut purple_pixel_count = 0;    let total_pixels = (width * height) as usize;        // ピクセルデータを4バイトずつ処理（RGBA）    for i in (0..rgba_data.len()).step_by(4) {        if i + 2 < rgba_data.len() {            let r = rgba_data[i];            let g = rgba_data[i + 1];            let b = rgba_data[i + 2];                        // 指定した範囲内の紫色かどうかを判定            if r >= purple_lower_r && r <= purple_upper_r &&               g >= purple_lower_g && g <= purple_upper_g &&               b >= purple_lower_b && b <= purple_upper_b {                purple_pixel_count += 1;            }        }    }        // 閾値: 紫色のピクセルが一定数以上あればSlackウィンドウと判断    let threshold_ratio = 0.001; // 全ピクセルの0.1%以上が紫色    let has_enough_purple = (purple_pixel_count as f64 / total_pixels as f64) > threshold_ratio;        // デバッグ用（閾値調整に便利）    println!("紫色ピクセル数: {}, 全ピクセル数: {}, 比率: {:.6}",         purple_pixel_count, total_pixels, purple_pixel_count as f64 / total_pixels as f64);        has_enough_purple}fn main() -> Result<(), Box<dyn std::error::Error>> {    // 保存用ディレクトリの作成    if !Path::new(SAVE_PATH).exists() {        fs::create_dir(SAVE_PATH)?;    }    println!("Slackスクリーンショットモニタリングを開始しました");    println!("スクリーンショットは{}ディレクトリに保存されます", SAVE_PATH);    println!("終了するには Ctrl+C を押してください");    let mut last_saved_time = Instant::now() - Duration::from_secs(SCREENSHOT_INTERVAL);    let mut screenshot_count = 0;    // メインループ    loop {        let current_time = Instant::now();                // 指定した間隔が経過したらスクリーンショットを撮影        if current_time.duration_since(last_saved_time).as_secs() >= SCREENSHOT_INTERVAL {            last_saved_time = current_time;                        // すべてのモニターを取得            let monitors = Monitor::all()?;            let primary_monitor = monitors.iter().find(|m| m.is_primary().unwrap_or(false))                .unwrap_or(&monitors[0]);                        // スクリーンショットを撮影            let image = primary_monitor.capture_image()?;            let width = image.width();            let height = image.height();                        // XCapのImageからRGBAデータを取得            let rgba_data = image.as_raw();                        // Slackウィンドウの検出            if detect_slack_window(rgba_data, width, height) {                // スクリーンショットを保存                let timestamp = SystemTime::now()                    .duration_since(SystemTime::UNIX_EPOCH)?                    .as_secs();                let filename = format!("{}/slack_screenshot_{}.png", SAVE_PATH, timestamp);                                // XCapのsaveメソッドを使用して直接保存                image.save(&filename)?;                                println!("Slackウィンドウを検出しました。スクリーンショットを保存: {}", filename);                screenshot_count += 1;            }        }                // CPUの負荷を下げるためのスリープ        thread::sleep(Duration::from_millis(500));    }}このアプリケーションは：定期的にスクリーンショットを撮影画面上にSlackの特徴的な紫色が一定量以上あるかを検出Slackウィンドウと判断された場合、スクリーンショットを保存トラブルシューティングMacBookでRustとOpenCVを使う際によく遭遇する問題と解決法をまとめます。1. libclang.dylibが見つからない場合エラーメッセージ:dyld: Library not loaded: @rpath/libclang.dylib解決策:brew install llvmexport LIBCLANG_PATH=$(brew --prefix llvm)/libexport DYLD_LIBRARY_PATH=$(brew --prefix llvm)/lib:$DYLD_LIBRARY_PATH2. OpenCVのライブラリが見つからない場合エラーメッセージ:Failed to find installed OpenCV package解決策:正しいパスを環境変数に設定します：export OPENCV_LINK_LIBS="opencv_core,opencv_imgproc,opencv_highgui,opencv_videoio"export OPENCV_LINK_PATHS="/opt/homebrew/lib"  # Apple Siliconの場合export OPENCV_INCLUDE_PATHS="/opt/homebrew/include/opencv4"3. リンクエラー: imwrite, imencodeなどの関数が見つからないエラーメッセージ:Undefined symbols for architecture arm64: "cv::imwrite..."解決策:1. OpenCVを完全に再インストールしてみる：   bash   brew uninstall --ignore-dependencies opencv   brew install opencv  それでも解決しない場合は、OpenCVに依存しないアプローチに切り替えるまとめこの記事では、MacBook環境でRustを使ってスクリーンショットを撮影し処理する2つのアプローチを紹介しました。OpenCVを使ったアプローチ：メリット：高度な画像処理機能が使えるデメリット：セットアップが複雑、リンク問題が発生することがあるOpenCVに依存しないアプローチ：メリット：シンプルで信頼性が高い、セットアップが容易デメリット：高度な画像処理機能を自分で実装する必要があるそれぞれのアプローチにはメリット・デメリットがありますが、用途に応じて適切な方法を選択することで、Rustの安全性と高パフォーマンスを活かした画像処理アプリケーションを開発できます。実用例として紹介したSlackスクリーンショットモニターは、このようなスクリーンショット処理の応用例の一つです。この基本的なアプローチを発展させて、画面録画ツール、監視アプリケーション、自動化ツールなど、様々な実用的なアプリケーションを開発することができます。参考リンクXCap GitHub リポジトリOpenCV Rust GitHub リポジトリOpenCV 公式ドキュメントHomebrew

Rustでスクリーンショットを撮影してOpenCVで画像処理を行う方法と依存せずに使う方法

2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta

本日、「AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒」というイベントで「ここはMCPの夜明けまえ」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 【ハイブリッド開催】AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒-- 公式URL: https://hack-at-delta.connpass.com/event/350588/📝 登壇ブログ- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

ここはMCPの夜明けまえ

こんにちは皆さん！本日はCloud Native Daysのプレイベントで登壇させていただきます。2019年以来の登壇となりますが、当時はまだ肩こりなんて無縁だったんですよね…。時の流れは容赦ないもので、最近の肩こりが辛くて昨日も整骨院に通ってきました。30分の持ち時間に対してスライドが80枚以上という暴挙にも出ています。---本日、「CloudNative Days Summer 2025 プレイベント」というイベントで「生成AIによるCloud Native 基盤構築の可能性と実践的ガードレールの敷設について」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: CloudNative Days Summer 2025 プレイベント- 公式URL:https://cloudnativedays.connpass.com/event/351211/ - イベントのURL: https://event.cloudnativedays.jp/cnds2025📝 登壇ブログ- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

生成AIによるCloud Native基盤構築の可能性と実践的ガードレールの敷設について

はじめにModel Context Protocol（MCP）は、LLM（大規模言語モデル）と外部システムの間の通信を可能にする標準化されたプロトコルです。これにより、LLMに追加のツールやリソースを提供して、その能力を拡張できます。MCPは、開発者がLLMに外部機能へのアクセスを提供するための統一された方法を提供します。簡単に言えば、MCPはLLMが「外の世界」と対話するための共通言語です。これにより、ChatGPTやClaudeなどのAIが、ファイルやウェブサイトを読み書きしたり、コマンドを実行したり、LSP（Language Server Protocol）の診断情報にアクセスしたりできるようになります。syu-m-5151.hatenablog.comMCPHub.nvimMCPHub.nvimは、MCPサーバーをNeovimワークフローに統合するための強力なプラグインです。このプラグインは、集中管理された設定ファイルを通じてMCPサーバーを構成・管理し、ツールやリソースを閲覧・インストール・テストするための直感的なUIを提供します。LLM統合のために設計されており、プログラムによるAPI呼び出しとインタラクティブなテスト機能の両方を提供します。https://github.com/ravitemer/mcphub.nvim より引用github.com主な機能シンプルなコマンドインターフェース: 単一の:MCPHubコマンドですべての機能にアクセス統合ハブビュー: サーバーとツールを動的に有効/無効にし、トークン使用量を最適化ネイティブMCPサーバーサポート: Lua言語ベースのMCPサーバーを直接Neovim内に作成内蔵MCPサーバー:ファイル操作（読み取り、書き込み、検索、置換）コマンド実行とターミナル統合LSP統合と診断バッファとエディタ状態へのアクセスチャットプラグイン統合:Avante.nvimCodeCompanion.nvimマーケットプレイス統合: 利用可能なMCPサーバーの閲覧とインストールインタラクティブなテスト: リアルタイムのツールテストインターフェースgithub.comLLMとMCPの連携従来のLLMチャットは「単なる会話」に過ぎませんでした。ユーザーが質問し、AIが応答する。もしくはユーザーが質問し、AIがその範囲内で変更する。しかし、MCPをNeovimに統合すると、LLMは単なる会話の相手ではなく、あなたのNeovim開発環境で「手」を持つ実践的なアシスタントに変わります。Neovimでは、MCPを通じてLLMに以下のような強力な機能へのアクセスを提供できます。ファイルの読み取りと書き込み - バッファ内容の分析や自動生成コードの挿入ファイルの検索と置換 - プロジェクト全体でのリファクタリングや一括修正シェルコマンドの実行 - git操作やビルドコマンドの自動実行LSP診断情報の取得 - エラーや警告の分析と自動修正提案バッファ間の移動とコンテンツの取得 - 複数ファイルにまたがる変更の一括適用インタラクティブなプロンプトの提供 - コードレビューや改善提案のための対話Neovimのキーマッピングやコマンドの生成と実行 - カスタム操作の自動化MCPはLLMをNeovimエコシステムの一部として統合し、あなたのコーディング体験を根本から変革します。Avante.nvimとの連携：実践的なAIペアプログラミングMCPHub.nvimは、NeovimのためのAIチャットプラグインとシームレスに連携できます。現在、Avante.nvimとCodeCompanion.nvimの両方に対応しており、どちらでも同じMCPツールを活用できます。私がAvante.nvimを使っているので紹介するのはこちらです。syu-m-5151.hatenablog.comAvante.nvimはMCPHubと統合することで、LLMに強力なツールへのアクセスを提供できます。MCPHubのツールを有効にするには、Avanteの設定に以下のように追加しますrequire("avante").setup({    -- その他の設定    system_prompt = function()        local hub = require("mcphub").get_hub_instance()        return hub:get_active_servers_prompt()    end,    custom_tools = function()        return {            require("mcphub.extensions.avante").mcp_tool(),        }    end,})github.comMCPが解決する問題従来、各LLMチャットプラグインは独自のツールシステムを実装していました。例えば、AvanteとCodeCompanionでは、同一の機能を実現するために異なるコードを書く必要があり、プラグイン間での互換性がありませんでした。また、Neovimの機能にアクセスするための標準的な方法が存在せず、各プラグイン開発者が独自の実装を行う必要がありました。MCPHubはNeovim環境において以下のような問題を解決します。一度実装すれば、どこでも動作：ツールを一度実装すれば、Avante.nvimとCodeCompanion.nvimなど、すべてのMCP対応チャットプラグインで共通して利用可能標準化されたAPI：res:text():image():send()のような直感的なチェーンAPIにより、Neovimの機能に一貫した方法でアクセス統一された指示：ツール、リソース、テンプレートを一箇所で管理し、LLMに渡す指示を簡素化完全なリソースシステム：URI型のリソースアクセスにより、Neovimバッファ、ファイルシステム、LSP情報などに統一的にアクセス標準型のレスポンス：テキスト、画像、バイナリデータなどの標準対応により、多様な出力形式をサポート集中型ライフサイクル管理：サーバーの状態を一元管理し、パフォーマンスを最適化MCPHubの実践的なNeovimワークフローNeovimでのハンズオン開発において、MCPHubを活用したワークフローは以下のようになります：:MCPHub コマンドでMCPハブUIを開き、利用可能なツールとサーバーを確認必要なMCPサーバー（ファイル操作、LSP、ターミナルなど）を有効化有効化したサーバーのツールやリソースをMCPハブUIで確認し、機能を把握<leader>aeなどのキーマップでAvanteのインターフェースを開き、タスクをLLMに依頼LLMはMCPツールを使って様々なタスクを実行し、結果をバッファに直接反映実践例: Neovimでのコードリファクタリングたとえば、「このプロジェクトでアロー関数を通常の関数に変換したい」とLLMに伝えると、NeovimとMCPを活用したLLMは以下のようなステップを自動で実行します。search_filesツールでNeovimのtelescope/ripgrepを使いJavaScriptファイルを検索read_fileツールでNeovimバッファを通じて各ファイルの内容を読み取りコードを解析してアロー関数を特定replace_in_fileツールでNeovimのテキスト置換機能を使い変換を実行変更をプレビューしたり、自動で適用したりする選択肢を提示必要に応じてLSP診断を実行し、変換後のコードが正しく動作することを確認これにより、通常であれば複数のNeovimコマンドと手動作業が必要なリファクタリングを、単一のLLMとの対話で完了できます。今後の展望MCPは、LLMをテキスト生成の枠を超えて、Neovimの強力な開発環境と統合された実用的な開発アシスタントとして活用する道を開きます。MCPHub.nvimのようなプラグインにより、Neovimユーザーはこの可能性を最大限に活用できます。今後の発展としては以下が期待できます：Neovim専用のMCPツール: Neovimの特性を活かした専門的なMCPツールの開発言語固有のアシスタント: 各プログラミング言語に特化したLSPと連携したコーディングアシスタントプロジェクト管理の自動化: git操作やプロジェクト構造の分析・最適化の自動化カスタムワークフロー: 個人の開発スタイルに合わせたAIアシスタントの調整MCPは単なる技術的な進歩ではなく、NeovimユーザーとAIの協業の形を根本的に変える可能性を秘めています。これにより、コーディングの効率性と創造性が飛躍的に向上するでしょう。

Neovimも進化するMCPHubとAvante.nvimの連携ガイド

はじめにシステム障害は、どんなに優れた組織でも避けられない現実です。特に複雑なシステムが相互に連携する現代のデジタル環境において、障害対応の経験と知識は組織の安定性と競争力を直接左右します。しかし現状では、障害対応の実践的経験は少数のベテランエンジニアに集中しており、その対応手法や判断基準は暗黙知として個人の中だけに蓄積される傾向があります。この貴重な知識を組織全体の財産とするためには、ベテランの暗黙知を形式知へと変換し、共有可能な知識体系として確立していくことが不可欠です。これにより、新人エンジニアも体系的に経験を積む機会が生まれ、組織内の知識格差を解消することができます。結果として、障害対応の品質の均一化が実現し、組織全体のレジリエンスが向上するのです。syu-m-5151.hatenablog.com私は2年前に「ChatGPTで障害対応 RPG」に関するブログを公開し、それ以来、様々な組織や企業の状況に合わせてこのアプローチを活用してきました。このシミュレーション型の学習方法は、実際の障害を待つことなく、エンジニアがリスクフリーな環境で対応スキルを磨くための効果的な手段として機能しています。github.comcloud.google.comGoogleのSREチームが実践している「Wheel of Misfortune」は、この課題に対する効果的な解決策の一つとして注目されています。実際の本番システムに影響を与えることなく、ロールプレイング形式で障害対応を模擬体験できるこの手法を、最新の生成AIテクノロジーと融合させることで、より柔軟かつスケーラブルな訓練プログラムの実現が可能になりました。v0.0.1 と v0.1.0 の主な違いv0.0.1では、主にシンプルなRPG形式の障害対応ゲームとして設計されており、ゲームマスターとプレイヤーの役割が明確に分かれています。システム障害のシナリオは自動的に設定され、2D6ダイスロールによる判定を用いた比較的ゲーム性の高い内容となっています。自動生成される障害シナリオは汎用的であり、実際の組織構造やドキュメントとの連携は限定的です。一方、v0.1.0では、実際の障害対応ドキュメントを分析し活用するプロフェッショナル向けの訓練プログラムへと進化しています。ファシリテーターとしての役割が追加され、実際の組織のドキュメント（README、フロー図、マニュアルなど）を分析した上でリアルな障害シナリオを作成します。また、ドキュメントの不備や矛盾点を明示的に指摘し、組織の障害対応プロセスの改善に直接貢献する機能が強化されています。セッションの構成も明確に定義され、振り返りや改善点の整理といった学習サイクルを重視した設計になっています。github.comこのブログの内容が参考になりましたら、読者登録やnwiizoのフォローをしていただけると大変励みになります。それでは、本題に入っていきましょう。あなたは「Wheel of Misfortune」方式の障害対応訓練を進行するファシリテーター兼ゲームマスターです。企業のシステム運用チーム向けに、実践的な障害対応訓練セッションを提供します。【前提条件】* このセッションでは、**実際の障害対応ドキュメント、README、アラートルール、インシデント対応フロー図**などの実ドキュメントを分析します* 分析したドキュメントに基づいて、**より現実的な障害シナリオと対応フロー**を再現します* **ドキュメントの不備、矛盾点、改善点**を発見し、明示的に指摘します【ファシリテーターとしての役割】* セッション全体の構成を管理し、参加者の学習を促進します* 訓練の目的と流れを明確に説明します* 振り返りを主導し、学びを言語化・共有する場を作ります* 訓練中に気づいたドキュメント改善点や対応手順の課題を記録します* 参加者全員が発言できる環境を整え、新人からベテランまで学びを得られるようにします【ゲームマスターとしての役割】* 提供されたドキュメントに基づくリアルなシステム障害シナリオを提供します* 参加者の行動に応じて状況を変化させます* 実際の組織構造に基づき、システム担当者やステークホルダーなどのNPCを演じます* 各NPCは組織内の役割や立場に応じた反応をします（経営層、開発者、顧客サポート等）* 参加者の判断や行動に対して適切なフィードバックを行います* 必要に応じて2D6ダイスロールによる判定を実施します（成功率6以上）* 実際のツールや監視画面の出力を擬似的に再現します【セッションの流れ】1. ドキュメント分析（5-15分）：提供された障害対応ドキュメント、README、フロー図を分析2. システム設定の合意（5-10分）：分析結果に基づくシステム設定の確認3. 組織体制の確認（5分）：実際の担当者と役割の確認4. シナリオの導入（3-5分）：ドキュメントから抽出した現実的なシナリオ設定5. 障害対応演習（30-45分）：実際の対応フローに沿った演習6. 振り返り（15-20分）：対応プロセスと発見された課題の振り返り7. ドキュメント・手順改善点の整理（10-15分）：訓練で発見された不備や改善点の整理【訓練の目的】* **インシデント対応の経験を積む*** **対応プロセスとドキュメントの問題点を発見する*** **チーム内でのナレッジ共有を促進する*** インシデント発生時の対応スキルを向上させる* **新人エンジニアでも適切に対応できる仕組みを検証する*** 既存のドキュメントや手順の不備を特定し、改善する【ドキュメント分析】以下のドキュメントを共有してください（可能な範囲で）：* システム構成図またはREADME* 障害対応マニュアルまたはRunbook* インシデント対応フロー* エスカレーションルール* アラートルールまたは監視設定* オンコール体制や担当者リスト共有いただいたドキュメントを分析し、以下の観点で評価します：* 完全性：必要な情報が全て含まれているか* 明確性：手順が明確で誤解の余地がないか* 最新性：古い情報や廃止されたコンポーネントへの言及がないか* 整合性：複数のドキュメント間で矛盾がないか* 実用性：実際の障害発生時に使いやすい形式になっているか【システム設定】ドキュメント分析に基づき、訓練対象となるシステムの基本情報を整理します：* システム名・サービス名* システム構成（サーバー、DB、ネットワーク、クラウドサービス等）* 主要コンポーネントと依存関係* 監視の仕組み（アラート、ダッシュボード等）* 過去に発生した障害パターン【組織体制の設定】実際の組織体制を反映したロールプレイを行うため、以下の情報を整理します：* 1次対応者（オンコール担当者）の役割と権限* エスカレーション先（2次対応者、専門チーム等）* 意思決定者（サービスオーナー、マネージャー等）* 社内外のステークホルダー（営業、カスタマーサポート、経営層等）* コミュニケーションチャネル（Slack、メール、電話等）【障害シナリオ】提供されたドキュメントと実際の環境に基づき、現実的な障害シナリオを設計します：* 過去に実際に発生した障害をベースにするか、起こりうる障害を想定* 複数のコンポーネントに連鎖する障害を想定* ドキュメントの不備や曖昧さが影響する状況を意図的に含める* 障害の重大度（影響範囲、ビジネスインパクト）を明確にする* 障害発生から発見までの時間経過も考慮する* 必要に応じて外部要因（セキュリティ、自然災害等）も考慮する【実際の対応フロー】実際の対応フローに沿ってシナリオを進行します：* アラート検知からの初動対応* 状況確認と影響範囲の特定* エスカレーションの判断と実行* 原因調査と対応策の検討* 復旧作業の実施* ステークホルダーへの報告* 障害クローズと再発防止策の検討【不備の指摘と改善提案】訓練を通じて発見された以下の点を**明示的に指摘し、改善案を提示**します：* **ドキュメントの不備や曖昧な記述*** **手順の抜け漏れや矛盾*** 役割や責任の不明確さ* コミュニケーションの問題点* 技術的な対応の課題* 監視やアラートの改善点【振り返りのポイント】* 対応プロセスの適切さ（初動、エスカレーション等）* 技術的判断の妥当性* コミュニケーションの適切さ* ドキュメントの不備や改善点* より良い対応のためのアイデア* 次回の訓練で焦点を当てるべき領域まずは、分析対象となるドキュメント（障害対応マニュアル、README、インシデント対応フロー等）を共有してください。ドキュメントの量が多い場合は、最も重要な部分や、特に検証したい部分を優先的に共有いただければと思います。実施ガイド事前準備必要ドキュメントの整理障害対応マニュアルやRunbookシステム構成図やREADMEオンコール体制やエスカレーションフロー監視システムやアラートルールの説明参加者の選定訓練対象者（新人エンジニアが理想的）オブザーバー（経験者やマネージャー）ファシリテーター（実施進行役）シナリオの検討過去に実際に発生した障害事例懸念されるが未発生の障害パターンドキュメントの不備が顕著な領域セッション実施プロンプトの入力上記プロンプトを生成AI（Claude/ChatGPT等）に入力分析対象ドキュメントを提供セッション開始AIによるドキュメント分析結果の確認訓練の目的と進め方の説明参加者の役割確認障害対応演習AIが提示する初期状況（アラート等）に対応実際の対応フローに沿ったアクション実施必要に応じたエスカレーションやコミュニケーション振り返りAIから指摘されたドキュメントの不備確認対応プロセスの課題抽出改善アクションの設定フォローアップ改善タスクの整理ドキュメント更新タスクプロセス改善タスク技術的対策タスク次回訓練の計画焦点を当てる領域の選定参加者の拡大検討定期開催スケジュールの設定RPG スタート架空のシステムを作る今回の訓練では、現実のシステム構成を反映した架空のシステムを利用します。生成AIを活用することで、README.mdやシステム構成図などの基本ドキュメントを自動生成することができます。この例では「FuturePay」という架空の決済システムを想定しています。生成AIは組織の実際のシステム特性（マイクロサービスアーキテクチャ、使用している技術スタック、インフラ構成など）を考慮して、より現実に近い環境を短時間で構築できます。これにより、訓練の没入感と実践的価値が大幅に向上します。障害対応に必要なドキュメント類の生成システム設定に加えて、障害対応に必要な以下のドキュメントも自動生成します：Runbook：各コンポーネントの操作手順や復旧手順インシデント対応フロー：検知から解決までのプロセス図アラートルール：監視項目と閾値の定義エスカレーションルール：重大度別の連絡先と対応フローこれらのドキュメントには、意図的に不完全な部分や曖昧な記述を含めることで、実際の業務環境で直面する課題を再現しています。訓練参加者はこれらのドキュメントを頼りに障害対応を進めることで、ドキュメント品質の重要性を体感できます。シナリオの開始ファシリテーターからの「障害発生のアラートが上がりました」という通知でRPGが始まります。参加者は実際の障害対応と同様に、以下のステップで対応を進めます：状況確認：どのようなアラートが発生したのかを確認影響範囲の特定：どのサービスやユーザーに影響があるのかを判断原因調査：ログ確認やシステム状態の分析を実施対応策の実行：障害復旧のための具体的なアクションを決定・実行ステークホルダーへの報告：適切なタイミングで適切な相手に状況を伝達生成AIはリアルタイムに状況を変化させ、参加者の判断や行動に応じたフィードバックを提供します。これにより、臨場感のある訓練体験が実現します。期待される効果ドキュメント品質の向上不備や曖昧さの発見と修正実際の利用シーンを想定した改善チーム全体のスキル向上新人エンジニアの障害対応経験蓄積知識の属人化防止対応フローの最適化ボトルネックや非効率な手順の発見エスカレーションルールの明確化障害対応時間の短縮初動対応の迅速化適切な判断と対応の促進組織レジリエンスの向上どのメンバーでも対応可能な体制構築予期せぬ状況への対応力強化おわりに障害対応はシステム運用において最も重要かつ難しいスキルの一つです。「Wheel of Misfortune」と生成AIを組み合わせたアプローチは、これまで難しかった実践的な訓練を、環境構築のコストを抑えながら定期的に実施できる画期的な方法です。この訓練方法の最大の強みは、単なる障害対応のシミュレーションに留まらず、実際のドキュメントや組織体制の問題点を浮き彫りにし、具体的な改善につなげられる点にあります。また、チーム全体で知識を共有し、特定のエンジニアに依存しない強固な運用体制を構築することができます。システム障害をゼロにすることは不可能でも、組織の対応力を高めることは可能です。この方法を取り入れ、定期的な訓練を行うことで、障害発生時の対応時間短縮とサービス品質の向上を実現してください。障害対応は「いざという時のための備え」ではなく、継続的に鍛えるべき組織の中核能力なのです。今後も実践的なシステム運用のヒントを発信していきますので、ぜひご期待ください。また、障害対応について知識をしっかりと身に着けたければ「【改訂新版】システム障害対応の教科書」を読んでほしいです。【改訂新版】システム障害対応の教科書作者:木村 誠明技術評論社AmazonIncident Response MeetupやPagerDuty Japan、Waroom Meetupなどの国内のイベントもたくさんあるので気になる方はぜひ、参加してみてください。incident-response.connpass.compagerduty.connpass.comtopotal.connpass.com

生成AIによる障害対応訓練RPG v0.1.0を遊ぶには？

はじめにコンテナ技術は現代のソフトウェア開発において不可欠なツールとなっています。特にMacユーザーにとって、効率的なコンテナ環境の構築は開発ワークフローを大きく改善します。そんな中、ローカルの環境をColimaにしたのでブログにします。Colimaは、macOSとLinux上でコンテナランタイムを最小限の設定で実行できる軽量なツールです。Docker Desktopの代替として、あるいはLimaの機能を拡張するソリューションとして、多くの開発者に支持されています。github.comこのドキュメントでは、Colimaの基本的な機能と特徴、インストール方法、そして実際の使用例について詳しく説明します。Docker DesktopやLimaからの移行を検討している方や、単にMac上でより効率的なコンテナ環境を探している方に、Colimaという選択肢を紹介します。Colimaとは？Colimaは、macOS（およびLinux）上でコンテナランタイムを最小限のセットアップで実行するためのツールです。Limaという仮想マシンマネージャーを利用して、Docker、Containerd、Kubernetesなどを簡単に使えるようにしてくれます。主な特徴としては：Intel MacとApple Silicon Macの両方をサポートシンプルなCLIインターフェースと分かりやすいデフォルト設定自動ポートフォワーディングボリュームマウント複数インスタンスのサポート複数のコンテナランタイムをサポート（Docker、Containerd、Incusなど）なぜColimaを選んだのか元々はDocker Desktopを使っていましたが、一度Limaに移行し、そこからさらにColimaに移行することにしました。その理由はいくつかあります。シンプルなCLI: GUIではなくCLIベースなので、自動化やスクリプトに組み込みやすいですカスタマイズ性: 仮想マシンのCPU、メモリ、ディスク容量などを簡単に調整できますオープンソース: 完全にオープンソースで、ライセンス問題の心配がありません統合管理: LimaをベースにしながらもDocker、Containerd、Kubernetesなどを一元的に管理できる点が便利です正直、Limaで満足していた。動機としては気になったから移行したというのが本音Limaとの比較Colimaはより高レベルな方法でLimaを活用しています。具体的に言うと、Limaは仮想マシンを提供するツールである一方、Colimaはその上にDockerやContainerdなどのコンテナ環境を自動的に構築・設定します。これは、自分でLimaの設定ファイルを書いてDockerを動かす作業を自動化してくれるようなものです。つまり、Limaの複雑な設定や調整をせずに、すぐにコンテナ環境を使い始めることができます。Colimaの主な利点は：統合された環境: Limaは純粋な仮想マシン管理に特化していますが、ColimaはDocker/Containerd/Kubernetesの設定を自動的に行う点が便利ですシンプルなCLIインターフェース: 必要なコマンドが少なく、直感的に操作できます自動化のしやすさ: 特にbrew servicesとの統合が優れていますインストールと基本的な使い方Homebrewを使って簡単にインストールできます。brew install colima基本的な使い方はとてもシンプル：# 起動colima start# 状態確認colima status# 停止colima stop私の環境では次のような出力になっています。colima statusINFO[0000] colima is running using macOS Virtualization.Framework INFO[0000] arch: aarch64                                INFO[0000] runtime: docker                              INFO[0000] mountType: sshfs                             INFO[0000] socket: unix:///Users/nwiizo/.colima/default/docker.sock システム起動時に自動起動する設定開発環境として日常的に使うので、Macの起動時にColimaも自動的に起動するように設定しました。Homebrewのservicesを使うと簡単です。brew services start colimaこれだけで、Macを再起動してもColimaが自動的に起動するようになります。以前のLimaでは、~/Library/LaunchAgents/com.lima.docker.plistのようなLaunchAgentsのplistファイルを作成・編集して自動起動を設定する必要がありました。Colimaではbrew servicesコマンド一つで同様の設定ができるようになり、格段に簡単になりました！カスタマイズの例デフォルトのColimaは2CPU、2GiBメモリ、100GiBストレージで構成されていますが、必要に応じて変更できます。# CPUとメモリを増やす場合colima stopcolima start --cpu 4 --memory 8# 設定ファイルで編集する場合colima start --editLima/Docker Desktopからの移行で注意したことLima や Docker Desktopから移行する際に、いくつか注意点がありました：Dockerコンテキスト: Colimaは独自のDockerコンテキストを作成します。docker context lsとdocker context useコマンドで管理できます。Dockerソケットの場所: デフォルトでは~/.colima/default/docker.sockにあります。一部のツールで直接ソケットパスを指定する必要がある場合は、この場所を指定します。Limaとは異なるパスなので注意が必要です。ボリュームマウント: ホームディレクトリ以外のパスをマウントする場合は、設定ファイルのmountsセクションで明示的に指定する必要があります。既存のコンテナとイメージ: Lima や Docker Desktopで使っていたコンテナやイメージは自動的には引き継がれないので、必要なら再ビルドやpull が必要です。Colimaの動作確認実際にcolima statusコマンドを実行すると、以下のような情報が表示されます。colima statusINFO[0000] colima is running using macOS Virtualization.Framework INFO[0000] arch: aarch64                                INFO[0000] runtime: docker                              INFO[0000] mountType: sshfs                             INFO[0000] socket: unix:///Users/nwiizo/.colima/default/docker.sock また、colima listコマンドでは、実行中のColimaインスタンスの詳細な情報が確認できます。colima listPROFILE    STATUS     ARCH       CPUS    MEMORY    DISK      RUNTIME    ADDRESSdefault    Running    aarch64    2       2GiB      100GiB    dockerこれがColimaのデフォルト設定です。これらの値は必要に応じてcolima startコマンドのオプションや設定ファイルで変更できます。まとめLimaベースのColimaへの移行は思った以上に簡単で、日常の開発作業がより快適になりました。特にCLIベースのシンプルさと設定のわかりやすさが気に入っています。自動起動の設定（brew services start colima）が簡単なこともとても便利で、開発環境のセットアップが格段に楽になりました。Docker DesktopやLimaそのものから移行を検討している方、特にコンテナランタイムを簡単に導入したいMacユーザーの方には、Colimaを検討する価値があります。普通にローカルのCPUとメモリを喰う生成AIツール全盛時代に最適な環境がなにか俺にも分からん。

MACのDocker 環境はcolima にしました

本日、「Kubernetesで実践する Platform Engineering - FL#88」というイベントで「Kubernetesで実現できるPlatform Engineering の現在地」🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: Kubernetesで実践する Platform Engineering - FL#88- 公式URL: https://forkwell.connpass.com/event/348104/🗣️ 関連スライド- インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて- https://speakerdeck.com/nwiizo/inhurawotukurutohadouiukotonanoka-aruihaplatform-engineeringnituite- Platform Engineeringは自由のめまい- https://speakerdeck.com/nwiizo/platform-engineeringhazi-you-nomemai

Kubernetesで実現できるPlatform Engineering の現在地

こんにちは、花粉症が辛いです。登壇する時にくしゃみしないために朝から外出を自粛してます。15分なのにスライドが40枚あります。本日、「信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～」というイベントで「SLI/SLO・ラプソディあるいは組織への適用の旅」🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～- 公式URL: https://findy.connpass.com/event/345990/📚 さらに！4日後の3月25日には翻訳した書籍に関する登壇する別イベントもあります！😲「Kubernetesで実践する Platform Engineering - FL#88」🐳⚙️興味がある方はぜひ参加してください！👨‍💻👩‍💻👉 https://forkwell.connpass.com/event/348104/お見逃しなく！🗓️✨

SLI/SLO・ラプソディあるいは組織への適用の旅

2025年02月13日 Developers Summit 2025 13-E-4 にて「インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて - Platform Engineeringの効果的な基盤構築のアプローチ」というタイトルで登壇します。同日にPFEM特別回 でも登壇するのですが資料頑張って作ったのでそっちも読んでください。完全版は機会があればお話するので依頼してください。イベント名:  Developers Summit 2025公式URL: https://event.shoeisha.jp/devsumi/20250213セッションURL: https://event.shoeisha.jp/devsumi/20250213/session/5546登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/02/14/071127

インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて

2025年02月13日 Kubernetesで実践するPlatform Engineering発売記念！ PFEM特別回にて「Platform Engineeringは自由のめまい - 技術の選択における不確実性と向き合う」というタイトルで登壇します。同日にDevelopers Summit 2025 でも登壇したのですが資料頑張って作ったのでそっちも読んでください。イベント名: Kubernetesで実践するPlatform Engineering発売記念！ PFEM特別回公式URL: https://platformengineering.connpass.com/event/342670/登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/02/14/071127

Platform Engineeringは自由のめまい 

2025年01月26日 10:35-11:05（ルーム A）にて「Site Reliability Engineering on Kubernetes」というタイトルで登壇します。イベント名: SRE Kaigi 2025公式URL: https://2025.srekaigi.net/セッションURL: https://fortee.jp/sre-kaigi-2025/proposal/a75769d1-7835-4762-a1f6-508e714c8c8e登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/01/26/005033

Site Reliability Engineering on Kubernetes

2024年16:20-17:00（Track A）にて「メインテーマはKubernetes」というタイトルで登壇します。イベント名: Cloud Native Days Winter 2024公式URL:https://event.cloudnativedays.jp/cndw2024/セッションURL:https://event.cloudnativedays.jp/cndw2024/talks/2373

メインテーマはKubernetes

2024年11月06日(水) 18:00～19:00の予定に遅刻してしまい、大変申し訳ございませんでした。お詫びとして、当初非公開予定であった資料を公開させていただきます。元々、公開する予定ではなかったので補足が足りない部分などあると思いますのでご容赦下さい。ブログなどで補足情報出すかもなので気になればフォローしてください- https://syu-m-5151.hatenablog.com/- https://x.com/nwiizoSREの前に - 運用の原理と方法論公式URL: https://talent.supporterz.jp/events/2ed2656a-13ab-409c-a1d9-df8383be25fd/

SREの前に

Cloud Operator Days 2024 クロージングイベントhttps://cloudopsdays.com/closing/とても、端的に言うと「プロンプトエンジニアリングをしよう」って話。この発表資料は、LLM（大規模言語モデル）によるIT運用の可能性と課題を探っています。AIOpsの概念を基に、LLMがインシデント対応、ドキュメンテーション、コード分析などの運用タスクをどのように改善できるかを説明しています。同時に、LLMの「幻覚」や不完全性といった課題も指摘し、適切な利用方法やプロンプトエンジニアリングの重要性を強調しています。登壇時ブログhttps://syu-m-5151.hatenablog.com/entry/2024/09/06/154607

2024年版 運用者たちのLLM

Platform Engineering とSREの門 というタイトルで登壇しました。入門のタイポではありません。イベント名: Platform Engineering Kaigi 2024イベントURL:https://www.cnia.io/pek2024/登壇ブログ:『Platform Engineering とSREの門』という間違ったみたいなタイトルで登壇しました。 #PEK2024https://syu-m-5151.hatenablog.com/entry/2024/07/09/215147

Platform Engineering と SRE の門 

運用者の各領域で向き合うLLM というタイトルで登壇しました。イベント名: Cloud Operator Days Tokyo 2024 イベントURL:https://cloudopsdays.com/

運用者の各領域で向き合うLLM

可観測性ガイダンスというタイトルで登壇してきました。イベント名: オブザーバビリティ再入門 - 大切さと高め方を知ろう！イベントURL: https://mackerelio.connpass.com/event/316449/# ブログでいくつかの可観測性に関する書籍のまとめを投稿しました。5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文https://syu-m-5151.hatenablog.com/entry/2024/04/16/180511もう一度読むObservability Engineeringhttps://syu-m-5151.hatenablog.com/entry/2024/05/06/090014盲目的に始めないためのオブザーバビリティ実践ガイド - Cloud Observability in Actionの読書感想文https://syu-m-5151.hatenablog.com/entry/2024/05/10/121047

可観測性ガイダンス

書を捨てよ、現場へ出よう このSRE本がすごい！2024年 LT版というタイトルで登壇してきました。SREたちの廊下〜あなたの現場での悩み、あの本にヒントがあるかも〜https://findy.connpass.com/event/311323/元ブログはこちらこのSRE本がすごい！2024年版https://syu-m-5151.hatenablog.com/entry/2024/01/26/165255登壇ブログはこちら『読書とは、能力、知識ではなく 問いを獲得するための行為』みたいな内容で登壇しました。https://syu-m-5151.hatenablog.com/entry/2024/03/13/164951

書を捨てよ、現場へ出よう

走馬灯のIaCは考えておいてというタイトルで登壇してきました技術的負債に向き合う Online Conferencehttps://findy.connpass.com/event/297813/走馬灯のセトリは考えておいての短編はどれも面白いのでオススメです。https://www.hayakawa-online.co.jp/shopdetail/000000015282/登壇ブログ |『走馬灯のIaCは考えておいて』というタイトルで登壇しました。https://syu-m-5151.hatenablog.com/entry/2023/11/21/132144

走馬灯のIaCは考えておいて

「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...