nwiizo

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 にしました

防御力の高い技術ブログを書こう

エンジニアブログは技術的であるべきで登壇は衒学的であると思う理由

生成AI時代に必要なシェルの基本知識とシェル芸への入門

3年目までに身につけたい技術ブログの書き方

Rust製MCPライブラリのサンプルコードから学ぶ活用法

Rust製MCPライブラリの内部実装を徹底解析

本日、「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 の現在地

はじめにこんにちは、スリーシェイクのnwiizoです。2025年3月21日に開催されたFindyさん主催のイベントで登壇してきました。findy.connpass.comイベント概要このイベントは、SLI/SLOの導入と運用に焦点を当てたライトニングトーク形式のセッションでした。サービス品質を高めるためのSLI/SLOですが、組織内での運用がうまくいってないケースや導入タイミングに悩まれている方も多いのが現状です。本イベントではSLI/SLOについて向き合っていらっしゃる4名の皆様に、導入までの取り組みや運用上の課題とその解決策を共有していただきます。参加者にとって今後システムの信頼性向上に取り組んでいくための知識やヒントを得られるイベントになることを目指します。私を含めた4名のスピーカーによる多角的なアプローチで、SLI/SLOに関する実践的な知見が共有されました。とても良い会だったと思います。私の発表内容資料 speakerdeck.com👻本日、「信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～」というイベントで「SLI/SLO・ラプソディあるいは組織への適用の旅」というタイトルで登壇します。こちら、資料になります。https://t.co/XtbFX2EOSH#信頼性向上_findy— nwiizo (@nwiizo) 2025年3月21日   発表の背景と位置づけこのイベントの準備にあたり、他の登壇者の方々の過去の発表や知見を事前に確認し、全体として何が語られるのかを予想してみました。技術的な実装方法や指標設計については他の方々が深く掘り下げられると考え、あえて私は「個人や組織への適用」という補完的な視点に焦点を当てることにしました。技術的な側面は重要ですが、実際にSLI/SLOが組織に定着するかどうかは、エンジニアリング以外の部分に大きく依存します。そこで今回は「技術をどう実装するか」ではなく「個人や組織をどう変革するか」という視点からSLI/SLOの旅を語ることにしました。発表の核心：三つの壁私の発表ではSLI/SLO導入における「三つの壁」に焦点を当てました1. 既存の習慣や方法からの変更を伴う壁「変化への抵抗」は克服すべき障害ではなく、理解し対話すべき自然な反応です。特に以下の4つの抵抗パターンを理解することが重要です。惰性による抵抗：「今のやり方で問題ない」労力による抵抗：「新しい方法を学ぶコストが高い」感情による抵抗：「自分の立場が脅かされる」心理的反発：変化に対する本能的な抵抗これらの抵抗に対して「北風」（強制）ではなく「太陽」（共感と対話）のアプローチが効果的です。2. 多くのステークホルダーとの協力が不可欠という壁SLI/SLOは技術だけの問題ではなく、むしろ組織の問題です。表向きは「全員で信頼性を高めましょう」という掛け声のもとで始まりますが、裏では様々な力学が働いています。部門間の隠れた対立構造：エンジニアリングは信頼性を重視し、プロダクトは新機能を優先し、経営層はコスト効率を求める。この三すくみの構造がSLI/SLO導入の最大の障壁になります。「会議では言えない本音」の存在：公式の場では皆が納得したように見えても、実際には「またエンジニアの自己満足では？」「数値のために本質を見失っている」といった潜在的な不信感が残ります。非公式なネットワークの重要性：公式のプロセスや説明会より、信頼関係のある個人間の非公式な対話の方が効果的なことが多いです。ランチタイムや1on1の場で地道に信頼関係を築く必要があります。技術と事業の懸け橋となる人材の重要性：各部門の言語を話せるクロスファンクショナルな理解者（技術と事業の両方を理解できる人）が不可欠です。このような架け橋となる存在を味方につけることが成功への近道になります。結局のところ、最も有効な戦略は「自分の専門領域を超えて相手の文脈で語る」ことです。技術者は事業KPIの言葉で、事業側は技術的制約の言葉で対話する努力が必要です。これが「信頼性は会話である」という言葉の本当の意味なのです。3. 目に見える成果が出るまでに時間がかかるという壁SLI/SLOの導入は短期決戦ではなく長期的な取り組みです。導入初期は一時的な作業量増加と基盤構築が先行本当の価値は6-12ヶ月後から現れることが多い「完璧なSLO」より「継続的に改善されるSLO」が重要長期的取り組みのためには、小さな成功の積み重ねと組織的なコミットメントが欠かせません。実務上の重要なポイントは、初期段階で期待値を適切に設定することです。多くの組織では「すぐに効果が出る」という期待から、半年程度で「効果がない」と判断されることがあります。これを防ぐには、短期的な小さな成功（例：アラート削減による疲労軽減）と長期的な大きな成功（例：システム安定性向上によるビジネス成長）の両方を明確に提示しておくことが重要です。発表を終えて今回のイベントでは、他の登壇者の方々もそれぞれの視点から素晴らしい発表をされていました。BASEのtandenさんがアラート品質の改善について、シンプルフォームの守屋さんが開発組織全体でのSLI/SLO実装について、ユーザベースの安藤さんがSREとCTOの両視点からのSLI/SLO活用について語られました。私は意図的に「組織文化と変革マネジメント」という視点から補完的に話すことで、イベント全体として技術から組織まで幅広い視点でSLI/SLOについて学べる場になったのではないかと思います。特に印象的だったのは、どの発表も「数値や指標そのものより、それを活用して何を実現するか」という本質的な部分を大切にしていたことです。形式的なSLI/SLO導入ではなく、真に組織とサービスの価値を高めるための取り組みとして捉えられていたのが印象的でした。まとめSLI/SLOの導入は一朝一夕にはいきません。それは旅のように、ゴールや完璧を目指すのではなく、継続的な前進が大切です。今日から始められることとしては：- 小さく始めて徐々に拡大する- まずは一つのサービスから- 既存の課題から出発するそして成功のための心構えとして：- 完璧よりも継続を重視する- 技術も情熱もどちらも大切- 信頼性は会話/対話から生まれるSLI/SLOの導入は技術的チャレンジであると同時に組織的チャレンジです。小さな一歩から始めて、組織全体で信頼性文化を育んでいきましょう。なお、SLI/SLOの基本概念から実践的な導入方法までを体系的に学ぶには、以下の書籍を必ず一読していただきたいと思います。組織への適用を考える前に、まずはこの本で基礎をしっかり固めることをお勧めします。www.oreilly.co.jpこれらのポイントを心に留めながら、組織にSLI/SLOを適用する旅を続けていきましょう。おわりにまた、他の登壇者の皆さんの発表資料も大変参考になりましたので、ぜひご覧ください。BASEの@tac_tandenさんによる「SLI/SLOの設定を進めるその前に、アラート品質の改善に取り組んだ話」では、SLI/SLO導入の前段階としてのアラート品質向上について詳しく解説されています。SREピラミットの下には常にモニタリングがあり自分の経験からも何よりも重要だと思っています。 speakerdeck.comシンプルフォームの守屋邦昭さんによる「開発組織全体で意識するSLI/SLOを実装している話」では、組織全体でのSLI/SLO実装について具体的な事例が紹介されています。 speakerdeck.comユーザベースの安藤裕紀さんによる「SREとしてSLI/SLOをどう普及してきたか、CTOとしてSLI/SLOをどう活用しているか」では、SRE視点とCTO視点の両面からSLI/SLOの活用方法が解説されています。個人的には俯瞰度合いが好きです。www.docswell.com最後までお読みいただき、ありがとうございました！

「SLI/SLO・ラプソディあるいは組織への適用の旅」というタイトルで登壇してきました。　#信頼性向上_findy

こんにちは、花粉症が辛いです。登壇する時にくしゃみしないために朝から外出を自粛してます。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・ラプソディあるいは組織への適用の旅

生成AIといっしょ: 動作するきれいなコードを生成AIとつくる

はじめに三寒四温（さんかんしおん）というような天気が続いています。これは「三日寒くて四日温かい」という意味で、冬から春への移行期によく見られる気温の周期的な変動を表す言葉です。寒暖の差が激しいこの季節、AIに関しての情報収集よりみなさんが暖かい格好して体調崩さないほうが大切です。とはいえ、技術ブログなので技術的なことも書いていきます。今回はPythonのAI用ブラウザである「browser_use」ライブラリを使用して、AnthropicのClaude 3.5 SonnetとOpenAIのGPT-4oの情報収集能力を実際のコードとログで比較します。github.com実際になにかに使う場合にはドキュメントを読んで下さい。このブログはそのようなことに耐えられるように作られてはいません。docs.browser-use.com環境構築まず、uvを使って環境を構築します。uvはPythonの高速パッケージマネージャーで、依存関係の解決と仮想環境の構築が効率的に行えます。# 仮想環境を作成uv venv# 仮想環境を有効化（macOS/Linux）source .venv/bin/activate# 必要なライブラリをインストールuv pip install langchain-anthropic langchain-openai browser-use実装コードAnthropicのClaudeを使用するコード（3shake_ceo_anthropic.py）:import asynciofrom browser_use import Agentfrom langchain_anthropic import ChatAnthropicllm = ChatAnthropic(model_name="claude-3-5-sonnet-latest")task = "株式会社スリーシェイクのCEOのXアカウントを教えて下さい"agent = Agent(    task=task,    llm=llm,)async def main():    await agent.run()asyncio.run(main())OpenAIのGPT-4oを使用するコード（3shake_ceo_openai.py）:import asynciofrom browser_use import Agentfrom langchain_openai import ChatOpenAIllm = ChatOpenAI(model="gpt-4o")task = "株式会社スリーシェイクのCEOのXアカウントを教えて下さい"agent = Agent(    task=task,    llm=llm,)async def main():    await agent.run()asyncio.run(main())実行結果(uv run xx.py)Claude 3.5 Sonnet（Anthropic）の実行ログINFO     [browser_use] BrowserUse logging setup complete with level infoINFO     [root] Anonymized telemetry enabled. See https://docs.browser-use.com/development/telemetry for more information.INFO     [agent] 🚀 Starting task: 株式会社スリーシェイクのCEOのXアカウントを教えて下さいINFO     [agent] 📍 Step 1INFO     [agent] 🤷 Eval: Unknown - Starting fresh with empty pageINFO     [agent] 🧠 Memory: Starting the task to find X (Twitter) account of 株式会社スリーシェイク's CEO. Step 1/100.INFO     [agent] 🎯 Next goal: Search for 株式会社スリーシェイク company information on GoogleINFO     [agent] 🛠️  Action 1/1: {"search_google":{"query":"株式会社スリーシェイク CEO Twitter X"}}INFO     [controller] 🔍  Searched for "株式会社スリーシェイク CEO Twitter X" in GoogleINFO     [agent] 📍 Step 2INFO     [agent] 👍 Eval: Success - Found search results showing the CEO's X accountINFO     [agent] 🧠 Memory: Found that the CEO of スリーシェイク is 吉田拓真 (Takuma Yoshida) and his X account is @taqqma_ikachan. Step 2/100.INFO     [agent] 🎯 Next goal: Visit the CEO's X profile to confirm informationINFO     [agent] 🛠️  Action 1/1: {"click_element":{"index":19}}INFO     [controller] 🖱️  Clicked button with index 19: 吉田 拓真 / スリーシェイク (@taqqma_ikachan) / XINFO     [agent] 📍 Step 3INFO     [agent] 👍 Eval: Success - I have confirmed that this is indeed the X account of the CEO of スリーシェイクINFO     [agent] 🧠 Memory: Found and confirmed that 吉田拓真 (Yoshida Takuma) is the CEO of スリーシェイク and his X account is @taqqma_ikachan. His profile confirms he is the 代表取締役社長 (CEO) of スリーシェイク.INFO     [agent] 🎯 Next goal: Task completed - provide the answerINFO     [agent] 🛠️  Action 1/1: {"done":{"text":"株式会社スリーシェイクのCEOのXアカウントは @taqqma_ikachan です。","success":true}}INFO     [agent] 📄 Result: 株式会社スリーシェイクのCEOのXアカウントは @taqqma_ikachan です。INFO     [agent] ✅ Task completedINFO     [agent] ✅ SuccessfullyGPT-4o（OpenAI）の実行ログINFO     [browser_use] BrowserUse logging setup complete with level infoINFO     [root] Anonymized telemetry enabled. See https://docs.browser-use.com/development/telemetry for more information.INFO     [agent] 🚀 Starting task: 株式会社スリーシェイクのCEOのXアカウントを教えて下さいINFO     [agent] 📍 Step 1INFO     [agent] 🤷 Eval: Unknown - The page is empty and there's no previous context to evaluate.INFO     [agent] 🧠 Memory: Need to find the X account of 株式会社スリーシェイク's CEO.INFO     [agent] 🎯 Next goal: Search for 株式会社スリーシェイク CEO Twitter account on Google.INFO     [agent] 🛠️  Action 1/1: {"search_google":{"query":"株式会社スリーシェイク CEO Twitter account"}}INFO     [controller] 🔍  Searched for "株式会社スリーシェイク CEO Twitter account" in GoogleINFO     [agent] 📍 Step 2INFO     [agent] 👍 Eval: Success - Google search is displaying links related to the CEO of 株式会社スリーシェイク and their X account.INFO     [agent] 🧠 Memory: Searching for 株式会社スリーシェイク CEO's Twitter account. Found potential link at index 26.INFO     [agent] 🎯 Next goal: Check the link at index 26 to verify if it leads to the CEO's X account.INFO     [agent] 🛠️  Action 1/1: {"click_element":{"index":26}}INFO     [controller] 🖱️  Clicked button with index 26: 株式会社スリーシェイク (@3shake_Inc) / XINFO     [agent] 📍 Step 3INFO     [agent] ⚠ Eval: Failed - The page requires login to access the X account information.INFO     [agent] 🧠 Memory: Currently on the login page of X; unable to access 株式会社スリーシェイク's CEO account information directly without logging in.INFO     [agent] 🎯 Next goal: Search again for 株式会社スリーシェイク's CEO X account from another source.INFO     [agent] 🛠️  Action 1/1: {"search_google":{"query":"株式会社スリーシェイク CEO X account"}}INFO     [controller] 🔍  Searched for "株式会社スリーシェイク CEO X account" in GoogleINFO     [agent] 📍 Step 4INFO     [agent] 👍 Eval: Success - Found a link that likely refers to the CEO's X account.INFO     [agent] 🧠 Memory: Trying to access 株式会社スリーシェイク CEO's X account via the link available at index 25.INFO     [agent] 🎯 Next goal: Click on the link at index 25 to verify if it leads to the CEO's X account.INFO     [agent] 🛠️  Action 1/1: {"click_element":{"index":25}}INFO     [controller] 🖱️  Clicked button with index 25: 内村一行/3-Shake (@KAZUYUKIUCHIMU) / XINFO     [agent] 📍 Step 5INFO     [agent] 👍 Eval: Success - Reached the login page for the user's X account.INFO     [agent] 🧠 Memory: Identified the CEO's Twitter handle as @KAZUYUKIUCHIMU, but login is required to access more information.INFO     [agent] 🎯 Next goal: Provide the CEO's X account and complete the task.INFO     [agent] 🛠️  Action 1/1: {"done":{"text":"The CEO of 株式会社スリーシェイク, 内村一行, has an X account with the handle @KAZUYUKIUCHIMU.","success":true}}INFO     [agent] 📄 Result: The CEO of 株式会社スリーシェイク, 内村一行, has an X account with the handle @KAZUYUKIUCHIMU.INFO     [agent] ✅ Task completedINFO     [agent] ✅ Successfullyコードとログの詳細分析browser_useの動作browser_useライブラリは、AIモデルをWebブラウジングと組み合わせて情報検索を行うエージェントを作成します。このライブラリはログを詳細に記録しており、AIの意思決定プロセスを追跡できます：🚀 Starting task: タスクの開始📍 Step N: 各ステップの開始🤷 Eval: ページの状態評価🧠 Memory: AIのタスク理解と記憶🎯 Next goal: 次の目標設定🛠️ Action: 実行するアクション📄 Result: 最終結果モデル間の違い1. 検索クエリの違いClaude: 株式会社スリーシェイク CEO Twitter XGPT-4o: 株式会社スリーシェイク CEO Twitter accountこの微妙な違いが、初期の検索結果に影響しました。2. 問題解決アプローチの違いGPT-4oは会社の公式アカウント（@3shake_Inc）をまず確認しようとしましたが、ログイン要求に遭遇して別の戦略に切り替えました。一方、Claudeは直接CEOのアカウントを検索してアクセスしました。3. 情報確認の徹底度Claudeはプロフィールにアクセスして「代表取締役社長」の肩書きを確認しましたが、GPT-4oは内村一行氏（実際は取締役）をCEOと誤認したままでした。技術的考察browser_useの利点詳細なログ: browser_useは各ステップを詳細にログに記録するため、AIの判断プロセスを追跡できます。シンプルなAPI: わずか数行のコードでAIエージェントを作成でき、異なるモデルの比較テストが容易です。多様なモデルサポート: browser_useは複数のAIモデルをサポートしており、異なるモデル間の比較が容易です。docs.browser-use.com改善ポイントログから以下の改善点が考えられます：1.検索クエリの最適化# より精度の高いクエリを指定task = "株式会社スリーシェイク 吉田拓真 CEO Xアカウント"2. 複数情報源からの検証agent = Agent(    task=task,    llm=llm,    verify_sources=True,  # 複数ソースでの検証を促す（仮想的なパラメータ）)3. エラー時の代替戦略# ログイン画面に遭遇した場合の対処を明示的に指示agent = Agent(    task=task,    llm=llm,    login_strategy="search_alternative",  # ログイン要求時の戦略)実務への応用AIエージェントを活用する際は、以下の点に注意すると良いでしょう：1. 正確なプロンプトの設計# より具体的なタスク指定task = "株式会社スリーシェイクの代表取締役社長/CEOの公式Xアカウントを会社の公式情報から特定してください"2. 複数モデルでの検証# 複数モデルの結果を比較results = {}for model_name in ["claude-3-5-sonnet-latest", "gpt-4o"]:    agent = create_agent_for_model(model_name)    results[model_name] = await agent.run()# 結果の一致度を確認compare_results(results)3. 結果の人間によるレビュー:特に重要な意思決定には、AIの判断をそのまま信頼するのではなく、人間による最終チェックを行うプロセスを組み込むことが重要です。結果に責任が取れるような仕組みにはまだなっていなさそうです。テスト的になにかのチェックを行わせるというのは必要かと思いました。まとめ今回の実験では、特別なプロンプトエンジニアリングやチューニングを一切行わず、同じコードで二つのモデルを実行した結果を比較しました。思いつきで雑に実行しただけなのに、興味深い違いが出てきたのは面白いポイントです。Claudeは正確にCEOを特定した一方、GPT-4oは取締役を誤ってCEOと判断しました。この結果は、AIエージェントがまだ完璧ではなく、特に重要な情報収集には複数の検証プロセスを設けることの重要性を示しています。今後も気軽に試せるツールとして、browser_useとuvの組み合わせは便利そうです。特に複雑な設定や調整をしなくても、こうした比較実験が簡単にできるのが魅力的です。docs.browser-use.com注：コード例は概念的なものであり、実際のbrowser_use APIとは異なる場合があります。詳細は公式ドキュメントを参照してください。

uvでbrowser_useを使用した環境構築したり比べたりするけど責任は取れない。

IntroductionHello! Today, I'd like to introduce a tool I recently developed called tfmcp. This tool allows you to operate Terraform from LLMs (Large Language Models) by utilizing the Model Context Protocol (MCP).github.comIf you like this project, please consider giving a Star to the GitHub repository to encourage development. Feedback is always welcome!What is MCP?Before diving in, let me briefly explain MCP (Model Context Protocol). For more detailed information, refer to the official documentation at modelcontextprotocol.io.Note: The image above is in Japanese but illustrates the MCP concept.MCP is a protocol that allows LLM clients like Cline or Cursor to connect with external services. Traditionally, LLMs could only "think" based on learned data, but with MCP, they gain the ability to "act" by connecting with external systems.MCP enables capabilities like:Editing files in NotionQuerying databasesChecking service statusEditing and operating local filesMCP is fundamentally a JSON-RPC-based protocol with three main components:Resources: Provide access to data (equivalent to REST API GET)Tools: Enable execution of actions (equivalent to REST API POST)Prompts: Guidance on how LLMs should use the servicetfmcp: Operating Terraform from LLMsNow, let me introduce tfmcp. It's a tool that utilizes MCP to enable operation of Terraform from LLMs (particularly Claude Desktop).Note: The image above is in Japanese but illustrates the tfmcp architecture.Main Features of tfmcpWith tfmcp, you can:Read and analyze Terraform configuration filesParse and explain Terraform plansApply Terraform configurationsManage Terraform stateCreate and modify configuration filesDemoHere's a demo of tfmcp working with Claude Desktop:In this demo, Claude operates a Terraform project through natural language commands.Installation and Setuptfmcp is written in Rust and can be easily installed using Cargo:cargo install tfmcpTo connect with Claude Desktop, find the path to the installed tfmcp executable and add it to Claude Desktop's configuration file:{     "mcpServers": {       "tfmcp": {         "command": "/path/to/your/tfmcp",         "args": ["mcp"],         "env": {           "HOME": "/Users/yourusername",           "PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin",           "TERRAFORM_DIR": "/path/to/your/terraform/project"      }    }  }}Technical Implementation in Rusttfmcp consists of these main components:tfmcp├── config      - Configuration management├── core        - Core logic├── mcp         - MCP protocol implementation├── shared      - Common utilities└── terraform   - Terraform integrationNote: The image above is in Japanese but illustrates the internal architecture of tfmcp.MCP Server ImplementationThe core of the MCP server is the McpHandler struct, which processes requests and executes appropriate Terraform commands:pub struct McpHandler<'a> {    tfmcp: &'a mut TfMcp,    initialized: bool,}impl<'a> McpHandler<'a> {    async fn handle_tools_call(        &mut self,        transport: &StdioTransport,        id: u64,        params_val: serde_json::Value,    ) -> anyhow::Result<()> {        let name = params_val            .get("name")            .and_then(|v| v.as_str())            .unwrap_or("");        match name {            "list_terraform_resources" => {                self.handle_list_terraform_resources(transport, id).await?;            }            "analyze_terraform" => {                self.handle_analyze_terraform(transport, id, &params_val).await?;            }            "get_terraform_plan" => {                self.handle_get_terraform_plan(transport, id).await?;            }            // Other tool handlers...        }        Ok(())    }}The MCP request/response flow:Note: The image above is in Japanese but illustrates the MCP request/response flow.Terraform ServiceThe Terraform service handles the actual integration with Terraform:pub struct TerraformService {    terraform_path: PathBuf,    project_directory: PathBuf,}impl TerraformService {    pub async fn apply(&self, auto_approve: bool) -> anyhow::Result<String> {        let mut args = vec!["apply", "-no-color"];        if auto_approve {            args.push("-auto-approve");        }        let output = Command::new(&self.terraform_path)            .args(&args)            .current_dir(&self.project_directory)            .output()?;        // Output processing        // ...    }        // Other methods for Terraform operations}JSON-RPC Implementationtfmcp uses Rust to implement the JSON-RPC 2.0 protocol:Note: The image above is in Japanese but illustrates the JSON-RPC implementation.The message types and transport are defined as follows:#[derive(Debug, Clone, Serialize, Deserialize)]#[serde(untagged)]pub enum Message {    Request {        #[serde(rename = "jsonrpc")]        jsonrpc: String,        #[serde(rename = "method")]        method: String,        #[serde(rename = "id")]        id: u64,        #[serde(rename = "params")]        #[serde(skip_serializing_if = "Option::is_none")]        params: Option<serde_json::Value>,    },    Notification { /* ... */ },    Response { /* ... */ },}#[async_trait]pub trait Transport: Send + Sync {    async fn send(&self, message: Message) -> Result<(), Error>;    fn receive(&self) -> Pin<Box<dyn Stream<Item = Result<Message, Error>> + Send>>;    async fn close(&self) -> Result<(), Error>;}Security ConsiderationsWhen using MCP tools like tfmcp, be aware that:They can create, modify, and delete infrastructureThey have access to local files and potentially sensitive informationUntrusted MCP servers could pose security risksImplement these safety measures:Only install MCP servers from trusted sourcesGrant minimum required permissionsRun in sandboxed environments when possibleEnable audit loggingFilter sensitive informationConclusiontfmcp represents a step forward in integrating Terraform with LLMs. By leveraging the Model Context Protocol, it provides a natural language interface to infrastructure management, simplifying complex IaC (Infrastructure as Code) tasks.MCP itself acts as a bridge allowing AI models to safely access local resources and tools. The implementation is based on a simple JSON-RPC protocol, making it accessible for developers to create their own MCP servers for specific domains.The Rust implementation provides benefits like type safety, robust error handling, and efficient asynchronous processing, creating a reliable foundation for smooth interaction between AI and tools.Reference LinksModel Context Protocol Official DocumentationMCP GitHub RepositoryAnthropic's MCP Introduction Article

tfmcp 🦀: A Rust-Implemented Tool to Operate Terraform from LLMs

MCPでLLMに行動させる - Terraformを例とした tfmcp の紹介

無限技術的負債 - Taming Your Dragon: Addressing Your Technical Debt の読書感想文

yamori demo gifgithub.comはじめに「あー、もう！競プロでテストの為にSolverを分けるの、マジで面倒くさい！」これが私がYamoriを作ったきっかけです。正直に言いましょう。私は怠け者です。AtCoderで問題を解くたびに、問題ごとにSolverを分けて、いちいちmain.rsを書き換えて...という作業が本当に億劫でした。標準入力でサクッとテストできないものかと常々思っていたのです。「標準入力でサクッとテストできないかな」と思いながら、コピペして実行して、出力を目視で確認する日々。ある日、特に複雑な問題で間違えたとき、「あれ？どのテストケースで落ちたっけ？」と混乱し、絶望的な気分になりました。そんな「プログラマーの怠惰」から生まれたのがYamoriです。「ヤモリ」という名前は、元々YAMLでテスト定義を書こうと思ったからです。（まあ、実際には「山守」という意味で、テストが私のコードを守ってくれるという願いも込めていますが、カッコいい理由なんて後付けです）「これでスッキリする！」という淡い期待競技プログラミングで使うRustのプログラムをテストするためだけに、Rustでテストツールを開発するという本末転倒な状況に、私は何の違和感も覚えませんでした。これぞ「釘を打つために、まず金槌を作るプログラマー」の鑑です。「単純な標準入出力のテストツールなんて、週末でサクッと作れるでしょ！」この甘い考えが、のちに何週間もの苦闘を招くとは思いもよりませんでした。ターミナルUIという沼「コマンドラインでテキスト出力するだけじゃつまらない。せっかくだから可視化もしたい！」この「せっかくだから」という言葉は、エンジニアの時間を無限に吸い取る魔法の呪文です。ratutuiというライブラリを見つけた瞬間、私は沼にハマりました。「タブがあって、色付きで、差分も表示できて、履歴も見れて...」気づけば、単純なテストツールのはずが、フルスクリーンのターミナルUIアプリケーションに進化していました。vim風のキーバインドを実装しながら「これ、競プロのテストに使うんだよね？」と自問自答する日々。言い訳のような機能たち最終的に、Yamoriには「競プロのテスト」という本来の目的を超えた様々な機能が実装されました：TOML/YAML形式のテスト定義（JSONじゃダメだったの？）履歴追跡機能（過去のテスト結果を見返す時間があるなら問題を解けよ）リリースモード切替（競プロでリリースビルド？本気？）カラフルな差分表示（赤と緑でお祭り気分）キーボードショートカット（vimmerの執着心）これらの機能を実装しながら、脳内では常に「ただテストするだけなのに...」というツッコミが再生され続けていました。しかし、完成したときの満足感は格別でした。最初のテストケースが緑色で「PASS」と表示されたとき、「こんなの作る時間があったら、もう10問解けてたな」と思いつつも、心のどこかでは「でも、これからはテストが楽になる！」という正当化が始まっていました。大切なものは ほしいものより先にきた結局のところ、Yamoriの開発は「標準入力でテストしたい」という単純な欲求から始まり、いつの間にか「立派なターミナルUIアプリ」へと成長しました。本当に必要だったのは単純なシェルスクリプトだったかもしれませんが、この回り道があったからこそ、Rustの理解も深まり、新しいライブラリにも触れられました。「効率的に競プロを解きたい」という目的からは大きく外れましたが、「プログラミングを楽しむ」という本質的な目的は達成できたのではないでしょうか。そして何より、次回のコンテストでテストケースを流し込むとき、「よっしゃYamori様様やな！」と密かに自己満足に浸れるのです。Yamoriを使ってみたいという変わり者の方は：cargo install yamoriで、この過剰なテストツールをインストールできます。あなたのターミナルをカラフルに彩るヤモリをぜひ体験してください！...そして私のように「本末転倒なツール開発」の罠に陥らないよう、ご注意を。

標準入出力テストを可視化するTUIツールの開発をした。

※カスハックの時間は終了して正式版に機能としてリリースされます。github.com免責事項: この記事は個人的な発見と試行錯誤を記録したものであり、正式なドキュメントに基づく推奨設定ではありません。ここで紹介する方法を実際の環境に適用する際は、十分な検証と自己責任でお願いします。はじめにこんにちは、Neovimユーザーのnwiizoです。今回は、NeovimでCopilotを使う際にAIモデルをClaudeに変更しようとして遭遇した「ちょっとした冒険」について共有したいと思います。最近、mizchiさんの最高のブログを読んだ。zenn.devこの記事を読んで魂を揺さぶられた。だが、まだVSCodeには移行しない。Neovimを使い続けることを決意した。揺らいだ。しかし、Neovim環境でもCopilotのAIモデルを自由に変更できたほうが良いと思い、特にClaudeモデルを試してみることにした。やりたかったこと最近、GitHub Copilotが Claude-3.7-sonnetなどのAnthropicのモデルをサポートするようになり、コーディング支援にもっと高度なAIの力を借りたいと思いました。GitHubの公式ドキュメント「Copilot Chat の AI モデルを変更する」によると、Copilot ChatのデフォルトLLMを別のモデルに変更できるようになっています。私のNeovim環境ではyetone/avante.nvimを使用してCopilotとの対話を行っていたので、このプラグインの設定でモデルを変更しようとしました。syu-m-5151.hatenablog.com最初の試み（失敗）まず試したのは、avante.nvimの設定で直接モデルを指定する方法です：{    "yetone/avante.nvim",    event = "VeryLazy",    lazy = false,    version = false,    opts = {      provider = "copilot", -- copilotを使用      auto_suggestions_provider = "copilot",      copilot = {        endpoint = "https://api.githubcopilot.com",        model = "claude-3.7-sonnet", -- ここでClaudeモデルを指定        timeout = 30000,        temperature = 0,        max_tokens = 4096,      },      -- 以下省略...    },    -- 依存関係などの設定...}しかし、この設定を適用してもなぜか期待通りの動作をしませんでした。デバッグを試みましたが、avante.nvimの設定だけではモデルの変更がうまく反映されていないようでした。というかこのような設定はたぶんなくて⋯。解決策：CopilotChat.nvimの力を借りる調査を進めるうちに、面倒になってCopilotC-Nvim/CopilotChat.nvimというプラグインの設定も変更しようと思いました。このプラグインはCopilotのチャットインターフェースを提供するもので、モデル設定も直接サポートしています。試しに以下の設定を追加してみました：-- Copilotチャット用の設定{  "CopilotC-Nvim/CopilotChat.nvim",  event = { "VeryLazy" },  branch = "main",  dependencies = {    { "zbirenbaum/copilot.lua" },    { "nvim-lua/plenary.nvim" },  },  opts = {    model = "claude-3.7-sonnet", -- モデル名を指定    debug = true, -- デバッグを有効化  },}そして驚いたことに、この設定を追加した後、avante.nvim側でもClaudeモデルが使われるようになりました！どうやら、CopilotChat.nvimの設定がcopilot.luaの基本設定に影響を与え、それがavante.nvimにも「引きずられて」反映されたようです。【注意】これは技術ブログ未満の個人的な発見であり、正式なドキュメントに基づくものではありません。このような依存関係による予期せぬ影響は、本番環境では深刻な問題を引き起こす可能性があります。設定の影響範囲を十分理解せずに適用すれば、システム全体に致命的な影響を及ぼす可能性があることを肝に銘じてください。なぜこうなったのか？正確な理由は不明ですが、おそらく両方のプラグインが同じzbirenbaum/copilot.luaに依存しており、この共通の依存関係を通じて設定が共有されたのだと思われます。CopilotChat.nvimがより直接的にCopilot APIとの連携部分を制御しているため、そちらでの設定が優先されたのでしょう。教訓Neovimのプラグインエコシステムでは、依存関係の連鎖によって予想外の相互作用が発生することがあります。今回のケースでは幸いにも望んだ結果につながりましたが、これは完全に「技術ブログ未満」の個人的な発見に過ぎません。警告: このような依存関係の連鎖による予期せぬ相互作用は、本番環境では極めて危険です。プラグイン間の隠れた依存関係による設定の「引きずり」は、デバッグが困難な問題を引き起こし、最悪の場合、本番システムの停止や重大なセキュリティ問題につながる可能性があります。設定変更の影響範囲を完全に理解しないまま適用することは、言わば地雷原を歩くようなものであることを忘れないでください。他の方も同様の状況に遭遇した場合、両方のプラグインを併用する方法が一つの解決策になるかもしれません。最終的な設定結局、私の設定はavante.nvimとCopilotChat.nvimの両方を含む形になりました：-- avante.nvimの設定（一部省略）{    "yetone/avante.nvim",    -- 省略...    opts = {      provider = "copilot",      auto_suggestions_provider = "copilot",      copilot = {        endpoint = "https://api.githubcopilot.com",        model = "claude-3.7-sonnet",        -- 省略...      },    },    -- 省略...},-- CopilotChat.nvimの設定{  "CopilotC-Nvim/CopilotChat.nvim",  event = { "VeryLazy" },  branch = "main",  dependencies = {    { "zbirenbaum/copilot.lua" },    { "nvim-lua/plenary.nvim" },  },  opts = {    model = "claude-3.7-sonnet",    debug = true,  },},これでNeovimでのコーディング体験がClaudeの能力で強化され、より的確なコード提案や説明が得られるようになりました。Neovimの設定は時に「魔法」のように思えることもありますが、それも含めて楽しいハック体験の一部なのでしょう。注：この記事は2025年2月時点の情報に基づいています。Copilotの仕様やプラグインの動作は変更される可能性があります。参考リンクGitHub Copilot Chat の AI モデルを変更する方法yetone/avante.nvimCopilotC-Nvim/CopilotChat.nvimzbirenbaum/copilot.lua

Neovimで使うCopilotのモデルをClaudeに変更する苦労話 - 技術ブログ未満の個人的体験談

📖 IntroductionWhen developing Rust projects, we frequently need to add new crates or remove unused ones. While Rust provides the cargo add command as a standard tool for managing dependencies from the command line:cargo add serde --features deriveHowever, cargo add requires manual execution and doesn't detect or remove unused dependencies. To further automate this dependency management process, I developed "cargo-autodd" 🚀.I developed "cargo-autodd", a CLI tool to automate dependency management in Rust. It analyzes use statements and extern crates to add required crates to Cargo.toml. Release planned this week with nvim support.https://t.co/ZNfOu4AxEd pic.twitter.com/Tsh0KzEiZV— nwiizo (@nwiizo) 2025年2月16日   🎯 What is cargo-autodd?cargo-autodd is a tool that automatically analyzes Rust source code to detect required dependencies and updates Cargo.toml accordingly.github.comKey features include:🔍 Analysis of use statements and extern crate declarations in source code🤖 Automatic detection of required crates⬆️ Addition of latest stable versions to Cargo.toml🗑️ Removal of unused crates⚡ Advanced analysis using rust-analyzer (optional)🛠️ Technical Details📊 Project Structure AnalysisThe analysis is centered around the DependencyManager struct, which has the following fields:struct DependencyManager {    project_root: PathBuf,  // Project root directory    cargo_toml: PathBuf,    // Path to Cargo.toml}🔄 Dependency Analysis ProcessThe analyze_dependencies method performs analysis in three stages:🚀 rust-analyzer Analysis (Priority)let output = Command::new("rust-analyzer")    .arg("analysis")    .arg("--workspace")    .current_dir(&self.project_root)    .output()?;📝 Regex Analysis (Fallback)let use_regex = Regex::new(r"use\s+([a-zA-Z_][a-zA-Z0-9_]*)(::|\s|;)")?;let extern_regex = Regex::new(r"extern\s+crate\s+([a-zA-Z_][a-zA-Z0-9_]*)")?;✅ Result Aggregation and VerificationRecords usage locations and feature flags for each detected crateExcludes standard library cratesEliminates duplicates📝 Cargo.toml Update MechanismThe update_cargo_toml method updates dependencies through the following steps:📖 Reading Current Dependencieslet content = fs::read_to_string(&self.cargo_toml)?;let mut doc = content.parse::<DocumentMut>()?;➕ Adding New Dependenciesfor (name, crate_ref) in crate_refs {    if !current_deps.contains(name) && !is_std_crate(name) {        self.add_dependency(&mut doc, crate_ref)?;    }}➖ Removing Unused DependenciesPreserves essential dependencies specified by is_essential_depfn is_essential_dep(name: &str) -> bool {    let essential_deps = [        "serde",        "tokio",        "anyhow",        "thiserror",        "async-trait",        "futures",    ];    essential_deps.contains(&name)}📈 Version Management DetailsVersion management is handled by the get_latest_version method with the following features:🌐 Fetching Latest Version from crates.io APIlet url = format!("https://crates.io/api/v1/crates/{}/versions", crate_name);🚫 Excluding Yanked Versionslet latest_version = response    .versions    .iter()    .find(|v| !v.yanked)?;🔢 Applying Semantic VersioningSpecifies only major and minor versionsAllows automatic patch version updatesOk(format!("^{}.{}.0", version.major, version.minor))📚 Best Practices and Usage Guidelines🔧 PreparationInstall rust-analyzer (recommended)Ensure project builds successfully🚀 Execution StepsRun cargo autodd in the project root directoryReview the changesPay special attention to version specificationsVerify dependency consistency with cargo check🔍 TroubleshootingFalls back to regex analysis if rust-analyzer is unavailableManually correct any falsely detected dependencies🔮 Future PlansFuture enhancements planned for cargo-autodd include:🔍 Enhanced AnalysisMacro expansion and dependency analysisMore accurate feature flag detectionConsideration of conditional compilation (cfg attributes)📦 Extended Dependency ManagementAutomatic management of dev-dependenciesEnhanced workspace supportAutomatic version conflict resolution💻 Improved Developer ExperienceEditor integration (e.g., VSCode extension)More detailed dependency graph visualizationCI automation options🎉 Conclusioncargo-autodd is a powerful tool for automating dependency management in Rust projects. Its strengths can be summarized in three key areas:⚡ Enhanced EfficiencyEliminates manual dependency management overheadMaintains project dependencies at latest necessary versionsImproves maintainability through automated version management🔒 Ensured SafetyAccurate dependency analysis using rust-analyzerProper handling of semantic versioningProtection of essential dependencies🎯 Improved Developer ExperienceSimple usage patternReduced maintenance time through automationClear visualization of project dependenciesThese features allow developers to focus more on essential coding tasks. As an open-source project, it continues to evolve through community feedback and contributions.cargo-autodd is expected to become an increasingly important tool as the Rust ecosystem matures. We hope it serves as an effective solution to the challenge of dependency management for many developers in the Rust community. 🚀日本語版:syu-m-5151.hatenablog.com

🦀 Automating Rust Dependency Management - A Deep Dive into cargo-autodd

はじめにRustプロジェクトを開発していると、新しいクレートを追加したり不要なクレートを削除したりする作業は頻繁に発生します。現在、Rustにはcargo addというコマンドが標準で用意されており、コマンドラインから依存関係を追加することができます。cargo add serde --features deriveしかし、cargo addは手動での実行が必要で、また使用していない依存関係の検出や削除は行いません。この依存関係の管理をさらに自動化できないか？という思いから開発したのが「cargo-autodd」です。Rustで開発する際の面倒な依存関係管理を自動化するツール「cargo-autodd」を開発しました。ソースコード内のuse文やextern crate宣言を解析し、必要なクレートを自動でCargo.tomlに追加します。先ほど作ったのでバグや不具合があると思うのでPRお願いします。テストもない。https://t.co/ZNfOu4AxEd pic.twitter.com/RbQNyp0K8H— nwiizo (@nwiizo) 2025年2月16日   cargo-autoddとはcargo-autoddは、Rustのソースコードを解析して必要な依存関係を自動的に検出し、Cargo.tomlを更新するツールです。github.com主な特徴は以下の通りです：ソースコード内のuse文とextern crate宣言を解析必要なクレートを自動検出Cargo.tomlに最新の安定バージョンを追加未使用のクレートを削除rust-analyzerを活用した高度な解析（オプション）技術的な詳細プロジェクト構造の解析プロジェクトの解析はDependencyManager構造体を中心に行われます。この構造体は以下のようなフィールドを持ちます：struct DependencyManager {    project_root: PathBuf,  // プロジェクトのルートディレクトリ    cargo_toml: PathBuf,    // Cargo.tomlのパス}依存関係の解析プロセスanalyze_dependenciesメソッドは、以下の3段階で依存関係を解析します：rust-analyzerによる解析（優先）let output = Command::new("rust-analyzer")    .arg("analysis")    .arg("--workspace")    .current_dir(&self.project_root)    .output()?;正規表現による解析（フォールバック）let use_regex = Regex::new(r"use\s+([a-zA-Z_][a-zA-Z0-9_]*)(::|\s|;)")?;let extern_regex = Regex::new(r"extern\s+crate\s+([a-zA-Z_][a-zA-Z0-9_]*)")?;結果の集約と検証検出された各クレートに対して、使用箇所とフィーチャーフラグを記録標準ライブラリのクレートを除外重複を排除Cargo.tomlの更新メカニズムupdate_cargo_tomlメソッドは、以下の手順で依存関係を更新します：現在の依存関係の読み取りlet content = fs::read_to_string(&self.cargo_toml)?;let mut doc = content.parse::<DocumentMut>()?;新規依存関係の追加for (name, crate_ref) in crate_refs {    if !current_deps.contains(name) && !is_std_crate(name) {        self.add_dependency(&mut doc, crate_ref)?;    }}未使用依存関係の削除ただし、is_essential_depで指定された重要な依存関係は保持fn is_essential_dep(name: &str) -> bool {    let essential_deps = [        "serde",        "tokio",        "anyhow",        "thiserror",        "async-trait",        "futures",    ];    essential_deps.contains(&name)}バージョン管理の詳細バージョン管理はget_latest_versionメソッドで行われ、以下の特徴があります：crates.ioのAPIを使用した最新バージョンの取得let url = format!("https://crates.io/api/v1/crates/{}/versions", crate_name);Yank済みバージョンの除外let latest_version = response    .versions    .iter()    .find(|v| !v.yanked)?;セマンティックバージョニングの適用メジャーバージョンとマイナーバージョンのみを指定パッチバージョンは自動更新可能にOk(format!("^{}.{}.0", version.major, version.minor))ベストプラクティスと使用上の注意点事前準備rust-analyzerのインストール（推奨）プロジェクトのビルドが通っていることを確認実行手順プロジェクトのルートディレクトリでcargo autoddを実行変更内容を必ず確認特にバージョン指定に注意を払うcargo checkで依存関係の整合性を検証トラブルシューティングrust-analyzerが使用できない場合は正規表現による解析にフォールバック誤検出された依存関係は手動で修正今後の展望cargo-autoddの将来的な機能拡張として、以下を計画しています：解析機能の強化マクロの展開とその依存関係の解析より正確なフィーチャーフラグの自動検出条件付きコンパイル（cfg属性）の考慮依存関係管理の拡張開発依存関係（dev-dependencies）の自動管理ワークスペース対応の強化バージョン競合の自動解決開発者体験の向上エディターへの組み込み（VSCode拡張など）より詳細な依存関係グラフの可視化CIでの自動実行オプションまとめcargo-autoddは、Rustプロジェクトにおける依存関係管理の自動化を実現する強力なツールです。その特徴は以下の点にあります：効率性の向上手動での依存関係管理の煩わしさを解消プロジェクトの依存関係を常に最新かつ必要最小限に保持バージョン管理の自動化による保守性の向上安全性の確保rust-analyzerを活用した正確な依存関係の解析セマンティックバージョニングの適切な処理重要な依存関係の保護機能開発者体験の改善シンプルな使用方法自動化による作業時間の削減プロジェクトの依存関係の可視化これらの機能により、開発者はより本質的なコーディング作業に集中できるようになります。また、オープンソースプロジェクトとして公開されているため、コミュニティからのフィードバックや貢献を受け入れながら、さらなる機能改善を進めていく予定です。cargo-autoddは、Rustエコシステムの成熟に伴い、より重要なツールとなることが期待されます。依存関係管理の自動化という課題に対する一つの解決策として、多くの開発者の方々に活用していただければ幸いです。English Edition:syu-m-5151.hatenablog.com

Rustの依存関係管理を自動化する - cargo-autoddの紹介

はじめにこんにちは、nwiizoです。2025年2月13日に2つのイベントで登壇する機会をいただきました。これは私が翻訳に関わった「Kubernetesで実践するPlatform Engineering」の発売を記念した販促登壇でしたが、原著者さんが書籍の内容自体について話をされると知っていたので、私はPlatform Engineeringという分野に関する自分なりの考えや経験を共有させていただく内容にしました。Kubernetesで実践する Platform Engineering作者:Mauricio Salatino翔泳社Amazon2つの異なるイベントでの発表同日に性質の異なる2つのイベントで話をさせていただきました。Developers Summitでは「インフラをつくるとはどういうことなのか、あるいはPlatform Engineeringについて」というタイトルで、幅広い技術者の方々に向けてPlatform Engineeringの基本的な考え方から実践的なアプローチまでをお話ししました。 speakerdeck.com一方、PFEM特別回では「Platform Engineeringは自由のめまい - 技術の選択における不確実性と向き合う」というテーマで、より専門的な視点からPlatform Engineeringの課題や可能性について話をしました。ただ、この回は資料作りや登壇などの疲れもピークに達していて、本来伝えたかったことと違う説明をしてしまった部分もあったように思います。 speakerdeck.com翻訳作業から得た気づき今回の発表の背景には、「Kubernetesで実践するPlatform Engineering」の翻訳作業があります。2025年2月19日に翔泳社から発売されるこの本は、"Platform Engineering on Kubernetes"の日本語翻訳版で、3-shake の同僚と一緒に取り組んだプロジェクトです。翻訳作業を通じて、Platform Engineeringの課題や可能性について考える機会を多く得ることができました。原著者のsalaboyさんのハンズオンや過去の発表資料、記事を読む中で、Platform Engineeringに対する彼の考え方を学ばせていただきました。実際に一緒に登壇する機会もいただき、私の拙い英会話力にも関わらず温かく接していただいたことも貴重な経験でした。登壇から学んだこと今回の登壇準備と実践を通じて、技術共有における重要な気づきがありました。最も重要だと感じたのは、聴衆のバックグラウンドに合わせて内容を適切に調整することです。Developers SummitとPFEM特別回では、参加者層が大きく異なりました。Developers Summitでは、DevOpsやPlatform Engineeringに詳しくない参加者が多く、日常的な開発における具体的な問題点から入り、それをPlatform Engineeringの文脈で捉え直すことで基礎的な理解を促しました。一方、PFEM特別回では参加者との間に共通認識があったため、より実践的な課題や技術的解決策について深く掘り下げることができました。この違いは技術資料の作成にも影響しました。資料作成では、「知的な発見」と「理解するためのコスト」のバランスが重要です。知的な発見とは「なるほど、そういう考え方があったのか」という新しい視点を得られる瞬間ですが、その発見に至るまでの説明が複雑すぎると理解へのコストが大きくなりすぎてしまいます。多くの技術プレゼンテーションでは既知の問題とその解決策を列挙することに終始しがちですが、それだけでは予想外の学びには至りません。予想外の学びこそが、聴衆の心に残る知的な発見として認知されやすいのです。ここで重要なのは、単に「よくある課題とその解決策」を並べるだけでなく、「明確には意識していなかったけれど、言われてみれば確かにそうだった」という新たな気づきを提供することです。例えば、日々の開発で感じている不便さを Platform Engineering の文脈で捉え直すことで、それが個人の問題ではなく構造的な課題だったと気づく瞬間を作り出せます。かといって基礎的な前提ばかりでは、聴衆にとって新しい気づきが得られません。Developers Summitでは基礎と新知見のバランスを重視し、PFEM特別回では基礎的な説明を最小限に抑え、より深い技術的な議論に時間を割きました。それ以外の「イライラ」「焦り」「困惑」といった感情は、むしろ読者の集中力を削ぎ、本質的な学びを妨げてしまう。技術資料は、共感と発見のポジティブな体験に徹するべきなのだ。確かに、高度な実装や複雑な概念を詰め込んだ資料を作ることは可能だ。しかし、そのような難解な内容は、読者の理解を遠ざけ、結果として伝えたい本質が埋もれてしまう。読者の多くがこのような否定的な感情を抱く資料は、作成者の自己満足に過ぎないと言えるでしょう。2025年ならではの発見として、Xのアルゴリズム変更により画像が優先表示されるようになった現在、印象に残るスライドを含めることが効果的です。複雑な概念を一枚の図で表現することで、SNS上での共有や議論が促進され、発表後もコミュニティでの対話が継続する可能性が高まります。また、Platform Engineeringという新しい分野では、技術コミュニティにおける「共通言語」の重要性も実感しました。Developers Summitではキーとなる概念を具体例と共に丁寧に説明し、PFEM特別回では既存の共通言語を活用してより専門的な議論を展開しました。知識を一方的に伝えるのではなく、参加者との対話を通じて互いに学び合える場を作ることを心がけ、翻訳者兼登壇者としての過剰な発言は控えました。この経験を通じて、技術を伝えることは単なる知識の転送ではなく、聴衆のコンテキストに寄り添いながら対話を生み出すプロセスだと実感しました。イベントの性質や参加者層によって求められる内容や深さが異なることを学び、今後もこの気づきを活かしながら効果的な技術共有を目指していきます。おわりに2つのイベントでの発表資料は異なる切り口で作成しましたが、どちらも力を入れて準備させていただきました。より詳細な内容についてはぜひ資料をご覧いただければと思います。また、完全版については機会があればお話させていただきたいと考えていますので、ご興味がありましたらぜひご依頼ください。最後に、この経験を通じて得られた知見を今後の活動にも活かしていきたいと考えています。ご清聴いただいた皆様、そして貴重な機会を提供してくださった関係者の皆様に心より感謝申し上げます。

nwiizo はなぜ同じPlatform Engineeringを語るのに、2つの異なる資料を作ったのか #devsumi #PFEM

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は自由のめまい 

github.blogこの設定は一時的なものであり、LSPのインストーラーが対応したらそちらで対応してください。github.comはじめに2025年2月10日、GitHubはCopilot Language Server SDKを公開しました。これは、エディタやIDEがLanguage Server Protocol（LSP）を通じてGitHub Copilotと連携できるものです。このリリースは、開発者がより柔軟にCopilotを利用できるようになる重要な一歩です。今までGitHub CopilotはVS Code、Visual Studio、JetBrains IDEs、Vim/Neovim、そして最近ではXcodeでも利用可能でしたが、これらのエディタすべてがCopilot Language Serverを使用して実装されていました。GitHubは開発者の選択肢を重視し、好みのエディタでCopilotを使用できるようにすることを目指しているみたいです。Copilotの進化NeovimでのCopilot利用は、以前はgithub/copilot.vimを通じて行われていました。このVimscriptベースのプラグインは、多くの開発者に利用されてきた公式の実装です。その後、Lua APIを活用したzbirenbaum/copilot.luaが登場しましたが、これも内部的にはcopilot.vimを通じてGitHub Copilotと通信を行っていました。このアーキテクチャでは、copilot.luaがNeovimのモダンなLua APIを活用した柔軟なインターフェースを提供し、バックエンドではcopilot.vimが実際のCopilotサービスとの通信を担当するという二層構造になっていました。そして今回のLanguage Server SDKの公開により、エディタとCopilotの連携方法が標準化され、直接Language Server Protocolを介してCopilotと通信できるようになりました。これにより、中間レイヤーが不要になり、より効率的で安定した実装が可能になりました。前提条件Neovim 0.8.0以上Node.js 18.x以上GitHubアカウント（Copilotのサブスクリプション）インストール手順1. Copilot Language Serverのインストールまず、Neovimの設定ディレクトリにCopilot用のディレクトリを作成し、Language Serverをインストールします。# Copilot用ディレクトリの作成mkdir -p ~/.config/nvim/copilot/# Language Serverのインストールnpm install @github/copilot-language-server -g --prefix ~/.config/nvim/copilot/# 実行権限の付与chmod +x ~/.config/nvim/copilot/bin/copilot-language-server2. Neovimプラグインのインストールlazy.nvimを使用している場合、以下の設定を~/.config/nvim/lua/plugins/copilot.luaに追加します。return {  "zbirenbaum/copilot.lua",  lazy = false,  priority = 1000,  config = function()    require("copilot").setup {      suggestion = { enabled = false },      panel = { enabled = false },      server_opts_overrides = {        trace = "verbose",        cmd = {          vim.fn.expand("~/.config/nvim/copilot/bin/copilot-language-server"),          "--stdio"        },        settings = {          advanced = {            listCount = 10,            inlineSuggestCount = 3,          },        },      },      filetypes = {        yaml = true,        markdown = true,        help = false,        gitcommit = true,        gitrebase = true,        hgcommit = false,        svn = false,        cvs = false,        ["."] = false,        ["*"] = true,      },    }  end,}3. 認証設定Neovimを起動後、以下のコマンドで認証を行います。:Copilot authブラウザが開き、GitHubアカウントでの認証が求められます。認証が完了すると、Copilotが使用可能になります。設定の説明設定の主要なポイントを解説します。この設定は私の設定ファイルなので自由に設定してください。suggestionとpanelenabled = false: デフォルトのサジェスト機能を無効化していますserver_opts_overridescmd: インストールしたLanguage Serverのパスと起動オプションを指定vim.fn.expand("~/.config/nvim/copilot/bin/copilot-language-server"): Language Serverの実行ファイルのパスを指定。vim.fn.expand()関数を使用して~をホームディレクトリに展開"--stdio": Language Serverが標準入出力（stdio）を使用してNeovimと通信することを指定するオプションsettings.advanced:   - settings.advanced:listCount: 候補の表示数（10個）inlineSuggestCount: インラインサジェストの数（3個）filetypes各ファイルタイプでのCopilotの有効/無効を設定["*"] = true: デフォルトですべてのファイルタイプで有効トラブルシューティングLanguage Serverが見つからない場合Error: Language server is not installed or not executableパスが正しいか確認実行権限が付与されているか確認chmod +xコマンドで実行権限を付与認証エラーの場合:Copilot authを再実行GitHubアカウントのサブスクリプション状態を確認まとめGitHub Copilot Language Server SDKの公開により、Neovimでより直接的にCopilotを利用できるようになりました。これまでのcopilot.vimを経由する方式から、直接Language Server Protocolを使用する方式への移行により、より効率的で保守性の高い実装が可能になりました。新しいSDKはnpmjs.comで公開されており、誰でも利用可能です。この変更により、エディタ開発者はより簡単にCopilotを統合でき、ユーザーはより安定した開発体験を得られるようになります。また、この方法は本来であれば不要でありlspconfigにコントリビューションすればよい()。github.com参考リンクGitHub Copilot Language Server SDK announcementCopilot.lua DocumentationLanguage Server Protocol SpecificationGitHub Copilot.vim

Neovimで始めるGitHub Copilot - copilot.lua による Language Server の設定方法

anond.hatelabo.jpこの記事を読み、その内容は学生だけでなく、ソフトウェアエンジニアの教育にも適用できると考えました。以下、ソフトウェアエンジニア（以降、技術者と表記）の教育について、私見を述べさせていただきます。はじめに新人エンジニアや学生のOJTやハンズオン研修を担当する中で日々実感することがあります。生成AIの台頭により従来の指導方法が大きく揺らいでいるという現実です。特に、表面的な成果物の質と実際の理解度の乖離が、技術者教育における新たな課題として浮き彫りになってきています。この変化は、技術教育に関わる私たち全員に、新たな挑戦と機会をもたらしています。生成AIは確かに技術教育の在り方を根本から問い直すきっかけとなりましたが、それは同時に、より本質的な技術力の育成について考え直す機会でもあります。技術の進化に伴う変化は不可避ですが、その中で私たちにできることは、この変化を前向きに捉え、新しい時代にふさわしい技術教育の形を模索していくことではないでしょうか。このような問題意識のもと、本稿では2025年に向けた技術者教育の新しいアプローチについて考察していきます。変化する学習の風景これまでの技術習得プロセスには、ある種の必然性がありました。ライブラリの使い方で躓き、設計パターンの意図を理解できず悩み、そしてそれらを一つずつ克服していく。この過程で、指導者は学習者の理解度を正確に把握し、適切なサポートを提供することができました。しかし、生成AIの登場により、この学習の構図が大きく変容しています。ある日の出来事が、この変化を象徴的に表していました。新人エンジニアに依頼した簡単なAPIの実装が、驚くほど短期間で、かつ高品質なコードとして提出されたのです。しかし、コードレビューの場での会話は、次のような展開となりました。「このミドルウェアの実装パターンを選択した理由は？」「はい...Copilotが提案したものをそのまま採用しました」「例外処理の設計思想については？」「申し訳ありません。その部分はAIの出力そのままで...」更に印象的だったのは、実装中のトラブルシューティングでの出来事でした。学生がハンズオン研修で詰まっていたため、私がエラーメッセージを確認して原因を特定し、問題のファイルを開こうとした瞬間、そのファイルは既にCopilotによって修正されました。本来であれば、エラーの原因を一緒に探り、解決策を考えることで、貴重な学びの機会となるはずでした。私たちはどう学んでいるのか　――創発から見る認知の変化 (ちくまプリマー新書)作者:鈴木宏昭筑摩書房Amazon理解を伴わない実装力技術者として、私自身も生成AIを積極的に活用しています。それは現代のソフトウェア開発において、もはや必須のスキルといえるでしょう。しかし、「理解を伴わない実装力」という新たな現象が、技術者教育に大きな課題を投げかけています。最近経験した出来事が、この課題を端的に表していました。新人エンジニアが実装したAPIは、一見すると申し分のない出来栄えでした。しかし、設計の意図を問うと「ChatGPTやCopilotの提案をそのまま採用した」という答えが返ってきます。エラーが発生した際も、その原因を一緒に探ろうとした矢先、Copilotが自動的に修正を施してしまう。こうした状況は、技術者としての本質的な成長機会を失わせる危険性をはらんでいます。具体的な例として、複雑なマイクロサービスアーキテクチャを構築できるのに、RESTful APIの基本原則が説明できない。網羅的なユニットテストを実装できるのに、テストピラミッドの考え方が理解できていない。Kubernetesのマニフェストが書けるのに、コンテナ化の利点を説明できない。このような状況が増えています。しかし、ここで注目すべきは「理解を伴わない実装力」にも異なるタイプが存在することです。生成AIに依存した実装を行うエンジニアと、知識はあるが実践との紐付けが発展途上のエンジニアです。前者は、高度なアーキテクチャのコードを書けるように見えても、その設計思想を説明できず、エラーが発生すると即座にAIに解決を委ねます。コードレビューでの「なぜ」という問いに対して、「AIが提案したから」や「はぁ？」という支離滅裂な回答に終始し、自身の実装に対する責任感や当事者意識が希薄です。一方後者は、デザインパターンやアーキテクチャの理論的理解はあるものの、それを実践に活かしきれていない段階にいます。しかし、レビューで指摘されると「あ、確かにそうですね」と納得し、エラーに直面しても自分なりの仮説を立てて解決を試みます。不完全でも自分の言葉で説明しようとする姿勢があり、試行錯誤を重ねながら、徐々に知識と実践を紐づけていっています。これまでの教育現場では、学習者の成長過程が自然と把握できていました。エラーメッセージと格闘し、設計パターンの意図を咀嚼し、少しずつ理解を深めていく。その過程で、「基礎概念は理解できている」「応用に課題がある」といった具合に、理解度の段階が明確だったのです。しかし今や、生成AIの支援により、理解度と実装力の相関が著しく弱まっています。特に前者のようなタイプの場合、表面的な成果物の品質だけでは、技術力を測ることが困難になっているのです。後者のような「知識はあるが実践が追いついていない」エンジニアの場合、時間とともに着実な成長が期待できますが、AIに依存した実装では、その成長機会自体が失われてしまう危険性があります。技術者教育の本質を見つめ直す私たちが目指すべきは、単なる「実装力」の向上ではありません。なぜその技術が必要とされるのか、どのような文脈で使用されるべきか、実装による影響をどう評価するか。そういった本質的な理解力を持つエンジニアの育成こそが重要です。「動くコード」を書けることは、技術者としての第一歩に過ぎません。技術力とは、技術選択の理由を説明できること、その技術がもたらす長期的な影響を予測できること、そしてプロジェクト全体における個々の実装の位置づけを理解できることです。これは単にコードを書けるということとは本質的に異なる能力です。syu-m-5151.hatenablog.comしかし、生成AIの存在は、この「理解のプロセス」を大きく変えつつあります。AIの出力を適切に編集することで「完成」にたどり着けてしまう現状は、技術習得における重要な学びの機会を奪っているかもしれません。エラーとの格闘、設計の試行錯誤、レビューでの指摘と修正—これらの経験は、表面的には非効率に見えても、実は技術者としての成長に不可欠なプロセスなのです。さらに重要なのは、技術の進化に対する適応力です。特定の実装パターンやツールの使い方を覚えることよりも、新しい技術が登場した際にその本質を理解し、適切に評価できる力を養うことが重要です。この適応力は、深い理解と経験に裏打ちされた「考える力」からしか生まれません。syu-m-5151.hatenablog.comこれからの技術者教育2025年に向けたエンジニア育成の新しいアプローチ1. 生成AIとの対話力を含めた包括的な技術教育カリキュラムの構築生成AIを効果的に活用するスキルそのものを技術教育の重要な要素として位置づける必要があります。AIへの適切なプロンプト作成能力はもはやエンジニアの基礎スキルとして不可欠です。しかし、ここで重要なのは単にAIに答えを求めることではありません。具体的には、AIに実装方針を提案させる際も、その根拠となる設計原則や参考文献を確認し、実装の背景にある理論や概念について理解を深めていく必要があります。さらに、特定の実装パターンのメリット・デメリットを比較検討させることで、技術選択の判断力を養うことができます。また、エラーが発生した際は、その原因と対処法についての理解を深めるための質問を重ねることで、問題解決力を育てていきます。つまり、AIを「答えを得るためのツール」ではなく、「理解を深めるための対話相手」として活用する姿勢が求められます。生成AIとの対話を通じて、技術の本質的な理解を深める習慣を身につけることが重要です。また、AIが出力したコードやドキュメントを適切に評価・検証する力も重要な要素となっています。プロンプトエンジニアリングの技術に加えて、AIと人間それぞれの得意分野を理解し、適切な役割分担ができる判断力が必要です。特に、AIの出力を鵜呑みにせず、常に批判的に検証し、その背景にある原理原則を理解しようとする姿勢を育むことが重要です。2. 実装スキルから設計思考力へのフォーカスシフトコーディングスキルの習得以上に、システム設計の原則や思想を理解することが重要になってきています。実装の詳細は生成AIに任せられる時代だからこそ、私たちはより本質的な設計思考力の育成に注力すべきです。システム設計において重要なのは、ビジネス要件を技術要件に適切に変換する力です。スケーラビリティ、可用性、保守性といった非機能要件をどのように満たすのか。開発効率と運用コストのバランスをどう取るのか。こうしたトレードオフを適切に判断し、プロジェクト全体の成功に導く力が、これからのエンジニアには求められます。個々の実装の詳細は生成AIにある程度任せられる一方で、システム全体を俯瞰する力は2025年においては人間にしか培えない能力なのです。この力を育むためには、実際のプロジェクトの中で判断が必要な場面に直面させ、その経験を積ませることが効果的です。例えば、新しい機能追加の要件を受けた際に、既存システムへの影響範囲を分析させたり、将来の拡張性を考慮した設計を検討させたりすることで、システム全体を見渡す視点を養うことができます。3. プロセスと思考を重視した評価方法への転換技術者の評価においても、成果物の完成度だけでなく、そこに至るまでの思考プロセスを重視する必要があります。なぜその設計を選択したのか、どのような代替案を検討したのか、想定されるリスクにどう対処するのか。こうした意思決定の過程とその根拠を、自分の言葉で説明できる力が極めて重要です。特に注目すべきは、長期的な視点での判断力です。目の前の実装だけでなく、その選択が将来的なシステムの保守性や拡張性にどのような影響を与えるのか。技術負債との向き合い方や、チーム全体での知識共有の方法など、持続可能な開発を実現するための視点も評価の重要な要素となります。この文脈で懸念されるのが、表面的な成果や「スムーズな進捗」を演出しようとする風潮です。これは特定の層に限った問題ではなく、現代の開発環境が生み出す構造的な課題といえます。重要なのは、そうした見せかけの生産性を求めない組織文化の醸成です。真摯な試行錯誤やチャレンジを認め、失敗から学ぶことを奨励する環境づくりこそが、本質的な技術力の向上につながります。結局のところ、私たちが目指すべきは、表面的な実装の速さや完成度ではなく、持続可能な開発を実現するための思考力と判断力を備えたエンジニアの育成なのです。そのためには、短期的な成果だけでなく、プロセスの質を重視する評価体系への転換が不可欠です。これは単なる評価方法の変更ではなく、組織全体で取り組むべき文化的な転換といえるでしょう。おわりに生成AI時代における技術者教育は、まさに過渡期にあります。単純な「できる/できない」の二元論では測れない、技術力をどう育成し、評価していくのか。これは私たち指導者自身にとっても、大きな学びの機会となっています。この課題に対する明確な解答は、業界全体としてもまだ模索段階にあります。しかし、技術教育の在り方を根本から見直し、新しい時代に適応した指導方法を確立していく必要性は明らかです。エンジニアの評価や育成に関する従来の常識は、生成AIの台頭により大きく揺らいでいます。多くの組織や教育機関が同様の課題に直面している中、重要なのは個々の取り組みや知見を共有し、業界全体として解決策を模索していく姿勢です。エンジニア育成は組織の壁を超えた共通の課題であり、オープンな対話と試行錯誤を通じてこそ、新しい時代にふさわしい技術教育の形が見えてくるのではないでしょうか。

滅びゆく「なぜ？」と「どうして？」の学びをどう受け止めればよいのか？新人エンジニアの指導で感じる生成AI時代の指導の難しさ

はじめにバズっている技術ブログやSNSの投稿を見ていて「今さらこんな基本的なTipsが数千いいねされるのか」と感じることはありませんか。「とりあえずDockerを使ってみよう」「React超入門」といった手取り足取り系の投稿がバズり続け、タイムラインには毎日のように初心者向けコンテンツが流れています。同じような入門記事が異なる執筆者によって際限なく生み出されるこの状況は、技術情報の共有における興味深い現象と言えるでしょう。では、なぜこのような現象が続いているのでしょうか。「学習」に対する一般的な認識多くの普通の人にとって「学習」は快適な体験であるべきだという認識があります。自分が理解できる範囲の内容を読み、既存の知識と結びつけて徐々に理解を深めていく。分からないことがあれば基礎的な内容に立ち返る。実際、人間の脳は安全な環境で学習することを好む傾向にあり、多くの人は「コンフォートゾーン」の中で学習を進めていきたいという自然な欲求を持っています。これは特に新しい技術やプログラミングのような複雑な分野においても顕著に表れます。このような学習パターンは、人間の認知的な特性とも合致しています。新しい情報は、既存の知識体系の中に無理なく組み込めるときに最も効果的に定着するからです。そのため、急激な学習曲線や理解が追いつかない内容は、多くの人にとってストレス要因となり、学習意欲を低下させる原因となり得ます。自己啓発の教科書　禁欲主義からアドラー、引き寄せの法則まで作者:アナ・カタリーナ・シャフナー日経ナショナル ジオグラフィックAmazon現実の技術学習との乖離しかし実際の技術習得のプロセスはもっと異なるものです。理解できない内容を何度も読み返し、エラーと格闘しながら少しずつ理解を積み重ねていく必要があります。分からない用語を調べながら文脈を理解していくという地道な作業が求められます。時には数時間かけてもエラーが解決できず、徹底的にドキュメントを読み込んだり、ソースコードを追いかけたりする忍耐も必要です。このような現実の学習プロセスは、多くの人が求める「快適な学習体験」とは大きくかけ離れています。つまり、技術習得には「コンフォートゾーン」を意図的に離れ、混乱や不確実性と向き合う覚悟が必要なのです。このギャップこそが「お手軽入門記事」が無限に生産され続ける根本的な理由の一つと言えるでしょう。人々は常により優しい入り口、より分かりやすい説明を求め続けているのです。私たちはどう学んでいるのか　――創発から見る認知の変化 (ちくまプリマー新書)作者:鈴木宏昭筑摩書房Amazon需要と供給の関係バズっている技術ブログやSNSでは特徴的な循環が生まれています。チュートリアル的なコンテンツへの大きな需要があり、入門記事の方が読者数やフォロワーを獲得しやすい傾向にあります。複雑な技術解説や深い考察よりも、「とりあえず動くものを作る」といった実践的なコンテンツの方が、圧倒的に高いエンゲージメントを得られるのです。このような状況下では、執筆者もまた市場原理に従わざるを得ません。高度な技術記事を書いても読者が少なければ、自然と入門コンテンツにシフトしていくでしょう。結果として、さらに多くの基礎的なハウツー記事が生み出され、SNSのタイムラインを埋め尽くしていく循環が続いています。これは技術情報の生態系における一種の「自然淘汰」とも言えるかもしれません。上級者向けコンテンツの価値と課題上級者向けコンテンツには確かに大きな価値があります。業界全体の技術力向上に貢献し、特定の問題に対する深い洞察を共有することで、エンジニアとしてのキャリアアップにも役立ちます。しかしこれらのコンテンツは必然的に読者層が限定されます。前提知識が必要で理解に時間がかかり、即座に実践できない場合が多いためです。視点の多様性と技術記事の価値重要な点として、技術記事の「難易度」は極めて相対的です。ある人にとっての入門記事が、別の人にとっては上級者向けのコンテンツとなるという状況は珍しくありません。私たちは往々にして自分の知識レベルをベースラインとして記事の価値を判断しがちですが、技術学習においてはそれぞれが異なる文脈や背景を持っているのです。この認識は、技術記事を書く際の重要な視点となります。プラットフォームと個人の戦略技術記事プラットフォームにはトレンドとは別に普遍的な価値を持つ記事が確実に存在します。分散システムの設計原則やスケーラビリティの考察、セキュリティアーキテクチャの分析など、時代を超えて参照される価値のある記事です。しかしそれらの記事はトレンド入りしづらく、時として埋もれてしまいます。質の高い技術記事が、読者の多様な技術レベルや興味に応じて適切に届けられる仕組みづくりがプラットフォーム側には求められています。一方で個人の執筆戦略としては、より包括的なアプローチが有効です。時にはトレンドに乗った入門記事を書きつつ、自分の技術的な知見や経験を活かした深い考察も定期的に発信していく。理想的な技術ブログの運営には、読者の多様性を意識したバランスが重要です。入門的なコンテンツから実践的な応用記事、さらにはアーキテクチャ設計や性能改善といった本質的な議論まで、幅広い層に価値を提供することができます。このような多層的なアプローチは、技術コミュニティ全体の成長に貢献します。それぞれの記事が、異なる段階にいる読者にとって「次のステップ」となる可能性を持っているからです。執筆者は自身の経験を共有しながら、同時に読者それぞれの文脈での学びをサポートすることができるのです。Science Fictions　あなたが知らない科学の真実作者:スチュアート・リッチーダイヤモンド社Amazonまとめ表層的な入門記事が無限に存在する現状は決して悪いことではありません。むしろそれは多くのエンジニアが学習意欲を持っている証であり、業界の健全性を示すものとも言えます。執筆者としては読者の「コンフォートゾーン」を少しずつ広げていけるような段階的な難易度設定と丁寧な説明を心がけることが重要でしょう。そうすることで読者の成長を支援しながら、技術コミュニティ全体の発展に貢献できるはずです。アメリカは自己啓発本でできている作者:尾崎俊介平凡社Amazon

技術記事のレベル低下は誰のため？ - 楽して学べる幻想と戦うためにもしくはバズるという快楽に対する防衛術

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は考えておいて

Platform Engineering Meetup #5 #PFEMhttps://platformengineering.connpass.com/event/295048/ SREとPlatform Engineerの交差点: 2つの領域の交差と組織への適用 というタイトルで登壇します。登壇ブログ |『SREとPlatform Engineerの交差点:2つの領域の交差と組織への適用』というタイトルで登壇しましたhttps://syu-m-5151.hatenablog.com/entry/2023/10/05/233555グレイラットの殺人 ワシントン・ポーが面白かったのでオススメです。https://www.hayakawa-online.co.jp/shopdetail/000000015569/

SREとPlatform Engineerの交差点

SREからPlatform Engineerへの拡大 というタイトルで登壇してきましたCloud Operator Days Tokyo 2023 運用の新時代　〜Effortless Operation〜https://cloudopsdays.com/クラウドインフラ運用技術者のための年次イベント「Cloud Operator Days Tokyo 2023」の見所を紹介https://cloud.watch.impress.co.jp/docs/news/1518302.htmlSREからPlatform Engineerへの拡大 というタイトルで登壇しました - じゃあ、おうちで学べる  https://syu-m-5151.hatenablog.com/entry/2023/08/10/150412 登壇しかないので20分しかないのでｷﾞｭｯとしてしまいました。

SREからPlatform Engineerへの拡大

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