nwiizo

おい、類推するな

RustでOWASP API Security Top 10を体験する（後編）：リソース制御と攻撃検知

RustでOWASP API Security Top 10を体験する（前編）：認証・認可の基礎とデータ保護

2025年12月5日に「おい、テックブログを書け」という登壇をした。「おい」である。命令形である。30分間、人前に立って「書け」と言い続けるという、冷静に考えるとなかなか傲慢な振る舞いをしてきたわけだが、登壇資料を作っている最中、ふと気づいてしまった。書けと言っている自分は、なぜ書いているのだろうか、と。技術ブログを書くことについて語ろうとすると、それは私が「書いてきた」ことを晒すことに他ならず、AIとの付き合い方を語ろうとすると、それは私が「どう仕事をしているか」を開陳することと紙一重になる。そうなると聞いている側からすれば、こいつは結局、自分の話がしたいだけなのではないか、登壇という大義名分を得て気持ちよく自分語りをしているだけなのではないか、と思われても仕方がない。いや、実際そうなのかもしれない。そう見られることへの嫌悪感と、そう見られまいと振る舞う自分への嫌悪感が同時に存在していて、どちらに転んでも結局イヤなやつなのである。しかし登壇というのは厄介なもので、「書け」と命令するからには、自分がなぜ書いてきたのかを明かさなければ説得力がない。説得力のない登壇ほど空虚なものはない。空虚な登壇をする自分を想像して、それはそれで耐えられない。結局、自己開示から逃げられない構造になっている。なんという罠だろうか。身体性という言葉を使った。AIに記事を書かせることについて話した。私の答えは明確で、記事はほとんどAIに書かせている、しかし価値の源泉は私にある、と。私が素材を提供し、AIが構造化し、私がレビューして調整する。編集者としてのAI。この協働こそが現代の執筆だと、そう話した。話しながら、これは本当にそうだろうかと自分を疑う自分がいて、でもそういう迷いごと引き受けて喋るしかないのだった。まず自分のために書け、結果として、それが誰かを救う。そう締めくくった。https://forkwell.connpass.com/event/377267/https://syu-m-5151.hatenablog.com/archive/category/%E3%81%8A%E3%81%84%E3%80%81自宅からの昼登壇だったので、終わってから昼飯を食べに外に出た。参考書籍として紹介した本をもう一度読み返そうと思って、鞄に入れてきていた。店に向かう道すがら、本を開く。

おい、テックブログを書け

おい、努力しろ

この記事は、3-shake Advent Calendar 2025 3日目のエントリ記事です。上巻の振り返り上巻では、Commandsを使ったブログレビュー環境の基礎を説明しました。/deep-thinking-prompt で書く前に深く考える/blog-quality-review で6つの観点からレビューする/ai-humanity-check でAIっぽさを検出する/full-review で全自動レビューするこれらのCommandsは、レビュー観点を構造化し、一貫性を担保してくれます。syu-m-5151.hatenablog.com下巻では、より高度なSubagentsの活用へ入る前に、いくつかの話題を深掘りします。AIに記事を書かせるとは何か「AIに記事を書かせる」という言葉をめぐって、しばしば議論が起きます。「それは本当にあなたの記事なのか」「AIが書いたものに価値があるのか」。私の答えは明確です。記事はほとんどAIに書かせています。しかし、価値の源泉は私にあります。手書きで書いているという人も別に紙に直接書いている訳ではないでしょう。既に、予測変換やLSP（Language Server Protocol）による補完など、さまざまなレベルで「AIやコンピュータの支援」を受けながら文章を書いています。その延長線上に、生成AIによる執筆があるに過ぎません。では、私は何を担っているのでしょうか。「身体性」を供給しています。ここで言う身体性とは、知識が「情報」から「経験」へと変容する過程で生じる、一人称的な認知の軌跡です。知識と経験の断絶たとえば、あるエンジニアがRustの所有権システムを学んでいるとします。The Bookを読み、概念は「理解した」つもりでいました。しかしいざコードを書くと、コンパイラからcannot borrow as mutable...というエラーを食らいます。「ルールは知っているはずなのに、なぜ」——この「知っている」と「書ける」の間にある断絶こそが、身体性が欠落している状態です。そして、その断絶を越えた瞬間の記録があります。「なぜエラーになったのか格闘し、イテレータの内部構造に気づき、腹落ちした瞬間」——これこそが身体性を伴った学習の言語化です。それは他者に伝達可能な「生きた知見」となります。この「苦闘から理解への遷移（プロセス）」だけは、AIには生成できません。AIは私の代わりに試行錯誤できませんし、私の代わりとしてコンパイラに叱られて悔しがることもできないからです。AIの役割は、私が供給した「生の体験（身体性）」を、他者が読める文章として整えることにあります。混沌とした思考を構造化し、読者にとって消化しやすい形に変換します。それは編集者の仕事に近いです。私が素材（身体性）を提供し、AIが構造化し、私がレビューして調整します。この協働のプロセス全体が、現代における「執筆」なのです。「流暢な嘘」という罠一方で、「AIで書いた記事には価値がない」という批判も、ある意味では正しいです。問題の本質は「AIを使ったこと」ではなく、「検証というプロセスが抜け落ちていること」にあります。AIに丸投げして出力された文章には、不正確な情報の垂れ流しという致命的なリスクが潜みます。厄介なのは、AIの生成する文章が文法的に完璧で、論理の構成も美しすぎることです。人間が書いた拙い文章なら「この人、理解していないな」と直感的に警戒できます。しかし、AIの出力は「もっともらしさ（Plausibility）」に特化しているため、嘘であってもスルスルと頭に入ってきてしまいます。これを検証せずに公開するのは、ブレーキの効かない車を公道に放つようなものです。LLMは確率的に「次の単語」を選んでいるに過ぎません。そこに真偽への誠実さは存在しません。だからこそ、その確率の波を制御し、事実という地面に杭を打つのは、人間にしかできない仕事です。私たちは、AIというエンジンの出力に酔うのではなく、冷静な「監修者」であり続けなければなりません。しかし、この監修作業を人間の力だけで行うには限界があります。だからこそ、「AIを監視するAI」が必要になるのです。それがこれから紹介する「Sub-agents」によるレビュー体制です。Commandsの限界とSub-agentsの登場上巻で紹介したCommands（/blog-quality-reviewなど）は便利ですが、長く使っていると2つの困難にぶつかります。コンテキストの枯渇: 長文記事に対し、複数の観点で深いレビューを繰り返すと、メインの会話履歴（コンテキストウィンドウ）がすぐに溢れてしまう。専門性の欠如: 1つのプロンプトにあらゆる指示を詰め込むと、焦点がぼやけ、鋭い指摘ができなくなる。そこで導入したのが、Claude Codeの強力な機能、Sub-agentsです。Sub-agentsとは何かhttps://code.claude.com/docs/en/sub-agents:embed:citeSub-agentsは、特定のタスクに特化した自律的なAIワーカーです。これまでの「Commands（定型文の挿入）」とは、根本的にアーキテクチャが異なります。1. コンテキストの分離（Context Isolation）これが最大にして最強のメリットです。通常、長い記事をレビューさせると、「思考過程」や「中間生成物」でメインの会話履歴が埋め尽くされてしまいます。しかしSub-agentsは、メインとは独立した別のコンテキストウィンドウで作業します。完全にレビュワーに徹することができます。もちろんデメリットもあるので使い分けが必要です。User │ ▼Main Agent │ [Delegate] 記事テキストを渡し、レビューを依頼 ▼Sub-Agent (Reviewer) ┃ ★独自のコンテキストで思考★ ┃ 1. 全文読み込み ┃ 2. 批判的検討 ┃ 3. 推敲（ここのトークンはメインには見えない） ┃ ▼Main Agent (レビュー結果の要約のみを受取) │ ▼User (修正案の提示)メインエージェントが受け取るのは、Sub-agentが導き出した「結論」だけです。これにより、メインのコンテキストを汚染することなく、大量のトークンを使った深い推論が可能になります。2. 自律的な委譲（Delegation）Commandsはユーザーが手動で呼び出すものですが、Sub-agentsはメインのエージェント（Orchestrator）が必要だと判断した時に自動的に呼び出されます。「この記事、なんか読みづらいから直して」と指示するだけで、メインエージェントが「これは『文章校正エージェント』と『構成作家エージェント』の出番だ」と判断し、仕事を割り振ります。私が実際に配備しているSub-agents私は現在、ブログ執筆チームとして以下のSub-agentsを .claude/agents/ に配備しています。実際にはもっといますが、今回は3つだけ実際に使っているものを紹介します。1. narrative-architect.md （物語構造の専門家）技術記事であっても、読者の感情を動かす「物語」が必要です。このエージェントは、技術的な正しさには口を出しません。その代わり、「読者の感情の旅路（Emotional Journey）」だけを見ます。役割: 導入で共感を得られているか。解決策の提示でカタルシスがあるか。指摘例: 「機能の説明は正確だが、読者が抱えている『辛さ』への共感が不足しており、解決策の価値が伝わりにくい」2. fresh-eye-reviewer.md （永遠の初学者）私の「書き手の呪い」を解くためのエージェントです。ペルソナとして「実務未経験のジュニアエンジニア」が埋め込まれています。役割: 専門用語の困難、論理の飛躍、「なぜ」という素朴な疑問の発見。特徴: 文脈をあえて読まない。「ここまでの説明では、この単語の意味がわからない」と冷徹に指摘する。3. ai-police.md （AI警察）「AIっぽさ」を検知し、排除する専門官です。AIが生成した文章特有の「過剰な接続詞」「中身のない美しいまとめ」「冗長な言い回し」を検挙します。役割: テキストの人間らしさ（Humanity Score）の判定。指摘例: 「『〜ということができる』は冗長だ。『〜できる』と言い切るべき。また、この段落の『いかがでしたか』はAI臭いので削除を推奨する」実践：レビュー体制の構築これらのSub-agentsを連携させることで、私のブログ執筆フローは完全に変わりました。ディレクトリ構造.claude/├── commands/           # ユーザーが叩くショートカット│   └── full-review.md  # 全体を統括する指示書└── agents/             # 自律的に動く専門家たち    ├── narrative-architect.md    ├── fresh-eye-reviewer.md    └── ai-police.mdレビューの流れStep 1: 執筆（協働）私とメインエージェントで対話しながら、記事のドラフトを作成します。私は身体性（エピソード）を話し、エージェントがそれを整えます。Step 2: 全自動レビュー（委譲）書き上がったドラフトに対し、私は一言こう告げるだけです。「/full-review を実行して」すると、メインエージェントが裏側で複数のSub-agentsを起動します。Fresh Eye が「ここがわからない」と文句を言う。Narrative Architect が「構成が退屈だ」と指摘する。AI Police が「AIっぽい表現がある」と警告する。Step 3: 統合と修正メインエージェントは、これらのバラバラな意見を統合し、優先順位をつけて私に提示します。「初学者にとって難解な部分があり、かつAI特有の冗長な表現が残っています。まずは第2章の具体例を修正しましょう」私はその統合されたレポートを見て、最後に修正します。まとめ上巻から下巻を通じて、生成AIエージェントを用いたブログレビュー環境の構築について解説してきました。上巻: ブログの評価基準をCommandsで構造化し、手動レビューの面倒臭さを解消する方法。下巻: Sub-agentsを用いてコンテキストを分離し、専門特化した「編集チーム」を作る方法。この環境を構築して気づいたのは、私の仕事が「執筆者（Writer）」から「編集長（Editor in Chief）」へとシフトしたということです。実際に手を動かして書く（Generate）のはAIでしょう。しかし、「何を書くか（企画）」「なぜ書くか（熱量）」「品質は十分か（承認）」を判断するのは、人間にしかできません。AIエージェントは、我々から仕事を奪うものではありません。我々を、より高次な意思決定を行う「マネージャー」へと押し上げてくれる存在です。もしあなたが「記事を書くのが面倒だ」「自分の文章に自信がない」と感じているなら、まずは小さなCommandを1つ作ることから始めてみてください。そこには、孤独な執筆作業とは違う、頼れるバディとの協働が待っているはずです。

生成AIエージェントによるブログレビュー環境の構築（下）

おい、がんばるな

この記事は、3-shake Advent Calendar 2025 2日目のエントリ記事です。はじめにブログを書いては直し、また直す。同じ文章を何度も触っていると、客観的な判断ができなくなってくる。「これで本当に伝わるのか？」という疑問だけが残る。コードにはレビューがあり、デザインには批評がある。しかし、技術ブログには明確な基準がない。その不安を解消するために、最初は自分の文章を評価する「プロンプト」を作って運用していた。防御力、思考整理力、実践応用性など、6つの観点でAIに評価させるのだ。だが、すぐに問題にぶつかった。「面倒」なのだ。記事を書くたびにプロンプトを開き、貼り付け、結果を待つ。この手動のひと手間があるだけで、次第に「今日はまあいいか」とサボるようになり、せっかくの基準も形骸化していった。だから、環境ごと変えることにした。生成AIのエージェント機能を使い、ブログレビューの手順をひとつの動作にまとめたのだ。/blog-quality-review と打てば、必要なチェックが勝手に走る。手間を消し、継続性だけを残す。今回は、そんなブログレビュー環境の構築について紹介する。syu-m-5151.hatenablog.comブログ記事評価プロンプト v2.1 https://syu-m-5151.hatenablog.com/entry/2025/05/19/100659 · GitHubこのブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、はじめていきます。なぜブログレビューにエージェントを使うのか自分で書いた記事を自分で評価するのは、想像以上に難しい。「こんなにわかりやすく書いたのに、なぜ伝わらないんだろう」と思うことはないだろうか。それは私たちが、自分の持つ知識や前提条件を、無意識に読者にも期待してしまうからだ。「これくらい知っているだろう」「説明不要だろう」という思い込みが、読者との間に溝を作る。ここにエージェントが入ると、話が変わる。エージェントは私の「暗黙の前提」を共有していない。だから、初学者が感じるであろう「分からない」を冷静に指摘できる。専門用語の壁、論理の飛躍、「なぜ？」という素朴な疑問——これらを容赦なく洗い出してくれる。さらに、エージェントは疲れないし、基準を忘れない。私が定義した「レビューの観点」を一貫して適用し続ける。これは単なる自動化ではない。私の認知リソースを、「本当に人間にしかできない判断」に集中させるための仕組みだ。Commandsでレビュー観点を構造化するClaude Codeには、よく使うプロンプトをコマンド化できる機能がある。.claude/commands/ ディレクトリにMarkdownファイルを置くだけで、ファイル名がコマンド名になり、中身がプロンプトとして機能する。code.claude.com「毎回『この観点でレビューして』と指示するのは面倒」「記事ごとにレビューの質がバラつくのが嫌だ」そんな悩みを抱えていた私にとって、Commandsは最適解だった。一貫性の担保手打ちのプロンプトでは、表現の揺らぎによりAIの回答も変わってしまう。Commandsなら常に同一の定義で実行されるため、出力の質が安定する。# 悪い例（毎回微妙に違う）「この記事をレビューして」「読みやすさをチェック」「AIっぽくないか見て」# 良い例（カスタムコマンド）/blog-quality-review blog.md# → 常に定義された6つの観点・同じ基準でレビューが走るGitでのVersion管理Commandsの実体はMarkdownファイルだ。つまり、プロンプトの改善履歴をGitで管理できる。「この観点を追加したら、指摘が鋭くなった」「この表現を変えたら、より具体的な改善案が出るようになった」こういった試行錯誤の軌跡が残ることで、プロンプト自体が「育つ資産」になっていく。私が実際に使っているCommandsここからは、私がブログ執筆・レビューで実際に使用しているCommandsを全てではないが紹介する。注意：ここで紹介するのは各Commandの要点のみだ。実際のファイルには、より詳細な指示や評価基準（Few-Shotなど）が含まれている。Phase 1: 書く前に深く考える良いブログは「書く」前に「考える」ことから始まる。/deep-thinking-prompt - 深い思考のための問いかけ# Deep Thinking Prompt - 深く考えるための問いかけブログを書く前に「深く考える」ための問いかけを提供します。表面的な理解や一般論で終わらず、本質に迫るための思考支援ツールです。## 7つの問いかけ1. **原体験への問いかけ** - なぜこのテーマに興味を持ったのか2. **前提への問いかけ** - 当たり前だと思っていることは何か3. **対立への問いかけ** - 矛盾や葛藤はどこにあるか4. **構造への問いかけ** - システムとしてどう機能しているか5. **変化への問いかけ** - 過去と現在で何が変わったか6. **未来への問いかけ** - このまま進むとどうなるか7. **読者への問いかけ** - 誰に届けたいのか、なぜその人なのかこのCommandを使うと、「何を書くか（What）」だけでなく「なぜ書くのか（Why）」が明確になる。一般論ではなく、自分だけの視点を掘り起こすための工程だ。/structural-thinking - 構造設計# Structural Thinking - 構造的思考支援散らばった思考を整理し、論理的な流れを作ります。読者の理解プロセスに合わせた「伝わる」構成を設計します。深く考えたあと、その思考をどう配置するか。このCommandが、散乱したアイデアを読者に届く「ストーリー」へと整えてくれる。Phase 2: 書いた後にレビューする/blog-quality-review - 6つの観点でレビュー以前作成した「ブログ記事評価プロンプト」をCommand化したものだ。# Blog Quality Review - ブログ品質レビュー以下の6つの観点（各0.0-5.0スコア）で評価します：1. **防御力** - 批判や反論への耐性2. **思考整理力** - 情報の論理的構造化3. **実践応用性** - 読者が行動に移せる価値4. **構成と読みやすさ** - 視覚的要素と文体5. **コミュニケーション力** - 人間味のある伝達6. **人間らしさ** - 温度感と個性実行すると記事の強みと弱みが数値化される。「前回は実践応用性が3.2だったが、今回は4.0に上がった」といった具合に、自身の成長や記事の品質を定量的に把握できる。/beginner-feedback - 初学者の視点# Beginner Feedback - 初学者の素朴な意見あなたは**一般読者代表（佐々木ゆい・28歳）**として、素朴な意見を提供します。- 専門用語や前提知識の壁を発見- 論理の飛躍を指摘- 「なぜ？」という素朴な疑問を投げかける- 一般読者が共感できるか確認エキスパートの目では見逃してしまう、初学者の「分からない」を発見するためのCommandだ。具体的なペルソナを設定することで、フィードバックの解像度を高めている。/ai-humanity-check - AIっぽさの評価# ai-humanity-check文章のAIっぽさを評価し、より人間らしい表現への改善提案を行います。## AIっぽさスコア (0.0-5.0) ※低いほど人間らしい**0.0-1.0 (完全に人間的)**- 著者特有の言い回しや癖がある- 具体的な失敗談や苦労話が生々しい- 感情の起伏が自然で共感できるAIに下書きを支援させると、どうしても文章が「AI臭く」なりがちだ。このCommandで機械的な表現を検出し、体温のある文章へと戻していく。Phase 3: 仕上げる/textlint-polish - 文章校正# Textlint Polish - 文章校正・AIっぽさ除去機械的・AIっぽい表現を排除し、自然で読みやすい文章にする。- AIが多用する冗長表現を検出- 比喩的・詩的すぎる表現を簡潔に- 文体の統一（です・ます調）textlint的な観点で、表現の誤りや揺らぎを修正する。AI特有の冗長な言い回しもここでカットする。/redundancy-check - 冗長性チェック# Redundancy Check - 冗長性チェック以下の4つの観点（各0.0-5.0スコア）で評価します：1. **情報密度** - 1文あたりの情報量2. **簡潔性** - 冗長表現・無駄な修飾の少なさ3. **論理効率** - 論理的重複・循環論法の少なさ4. **構造最適性** - 章・節の構成の必要十分性削れる言葉は徹底的に削る。情報の密度を高め、読み手の時間を奪わない文章にするための最終チェックだ。全自動レビューの実行これらを一つずつ実行するのはやはり手間だ。そこで、これらを束ねる /full-review を作成した。# Full Review - 全自動レビュー実行すべての必須レビューを自動で順次実行します。textlint校正から始まり、初学者フィードバック、品質レビューまで一括で実施。## 使用方法/full-review blog.mdこのCommandひとつで、以下のフローが流れる。/textlint-polish（校正）/beginner-feedback（初学者視点）/blog-quality-review（品質スコア）/ai-humanity-check（人間らしさ）一度設定さえしてしまえば、あとは「コマンド一発」で包括的なレビューが完了する。上巻のまとめここまで、Commandsを使ったブログレビュー環境の基礎（Phase 1〜3）を解説してきた。出発点は、「ブログ記事の評価基準がなく、レビューが属人的かつ面倒」という課題だった。これに対し、エージェントを活用して評価観点を構造化し、実行を自動化するというアプローチをとった。ここで重要なのは、AIとの関係性だ。体験や感情といった「身体性」は人間が供給し、それを構造化し整える役割をAIが担う。これはAIへの丸投げではなく、互いの強みを活かした協働である。Commandsによって評価基準を定義し、Gitで管理し、自動化することで、「書くこと」以外のノイズを極限まで減らすことができる。下巻では、より高度なAgents（サブエージェント）の活用と、複数の視点を持つレビュー体制の構築について解説する。下巻に続くsyu-m-5151.hatenablog.com

生成AIエージェントによるブログレビュー環境の構築（上）

「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？ — Just use Postgres 読書感想文

おい、本を読め

Fish Shell の abbr で使う。キミが好きだよ、エイリアス

たぶん、読んでない

おい、対話しろ

上手に待つ技術：Rust Edition 2024で学ぶ非同期処理入門

おい、つなげろ

おい、言語化しろ

配属から八年。僕はチームリーダーになっていた。ある日、後輩の山田が興味深いことを言った。「先輩って、いつもパッと2つか3つ答えますよね。なんでちょうどそのくらいなんですか？」確かに。APIが遅ければ「キャッシュかインデックス」。バグが出れば「ログかデバッガーかスタックトレース」。言語を選ぶなら「ShellかPythonかRust」。「経験則だよ。過去に何度もやってきたパターンが、自動的に浮かんでくるんだ」「でも、なんで1つじゃなくて、4つでもなくて、2つか3つなんですか？」言われてみれば、不思議だった。その夜、僕は過去のケースを思い返してみた。パフォーマンス問題：「キャッシュかインデックス」（2つ）セキュリティ脆弱性：「バリデーション、SQLインジェクション対策、認証強化」（3つ）コードの可読性：「変数名の改善か関数分割」（2つ）ある時は2つ、ある時は3つ。でも4つ以上になることはほとんどない。なぜだ？翌週、僕は田中さん（今は部長）にこの疑問をぶつけた。「田中さん、なんで僕ら、いつも2つか3つしか思い浮かばないんでしょう？」田中さんは笑った。「それはな、脳の処理能力の限界なんだよ」「限界？」「人間の作業記憶は、だいたい3〜4個のチャンクまでしか同時に保持できない。だから無意識に、その範囲内で候補を絞り込んでる。2つか3つがちょうどいいんだ」なるほど。経験則というより、認知的な制約だったのか。でも田中さんは続けた。「ただし、そこには罠がある」「罠？」「2つか3つで思考が止まってしまう。本当は4つ目、5つ目にもっといい答えがあるかもしれないのに」その言葉が頭に残った。数日後、小さなシステム障害が発生した。僕の頭に浮かんだのは「データベースの負荷」「ネットワークの問題」の2つ。いつものパターンだ。両方チェックしたが、どちらも正常。行き詰まった。そこに新人の佐藤さんが言った。「先輩、もしかしてタイムゾーンの設定、変わってませんか？」「タイムゾーン？」確認すると、前日のデプロイでサーバーのタイムゾーン設定が変更されていた。それが原因で、スケジュールされたバッチ処理が予期しない時間に実行され、システムに負荷をかけていた。僕の頭には、その選択肢が浮かばなかった。「いつもの2つ」で思考が停止していた。山田が僕に尋ねたあの質問の答えが、ようやくわかった。2つか3つというのは、経験則であると同時に、認知的な制約でもある。便利だが、危険でもある。その夜、僕はメモを更新した。かつてこう書いていた：「無意識の候補絞り込みに注意。定期的に立ち止まって再考する」今はこう書き直した：「脳は自動的に2〜3個に絞る。便利だが、それが答えの全てではない。4つ目を探せ」翌朝、山田が報告に来た。「先輩、このエラー、認証の問題かセッションの問題だと思うんですけど...」「それで終わり？」「え？」「3つ目は？4つ目は？」山田は戸惑った顔をした。「いや、もっとあるかもしれないけど、パッと浮かぶのはこの2つで...」「そう。パッと浮かぶのは2〜3個なんだ。でも本当の答えは、浮かばなかった4つ目にあるかもしれない」山田の表情が変わった。「じゃあ、どうすれば？」「まず、なぜその2つが浮かんだのか考える。次に、意識的に視点を変えて、他に何があるか探す。そして人に聞く」それから五年。今、僕が後輩を指導するとき、必ずこう言う。「パッと浮かんだ答えは、おそらく正しい。でも必ず4つ目を探せ。それが君を成長させる」脳は2〜3個に絞る。それは人間の性質だ。でも、その枠を超えようとすることが、エンジニアとしての本当の成長なのだと、僕は学んだ。

自動選択と成長

おい、内省しろ

おい、冷笑すんな

スタンドオフに学ぶ非同期プログラミング - 待ち時間を無駄にしない技術

おい、スマホを置け

おい、一つずつやれ

はじめにどれだけ技術を学んでも、どれだけ正しいプロセスを知っていても、燃え尽きてしまったら意味がない。才能ある若者たちが最初は誰よりも速く理解して、誰よりも多くのコードを書いていたのに、数ヶ月後には姿を見せなくなる。「疲れた」と言って離れていく。逆に、最初は遅くても数年経った今も黙々と学び続けている人たちがいる。彼らに共通しているのは、自分を大切に扱う習慣を持っていることだった。ちゃんと眠る。ちゃんと食べる。ちゃんと休む。そしてちゃんと掃除する。その中でも最も基本的な実践が、掃除だ。在宅勤務を始めて六年目のある朝、ふと自分の部屋を見回した。今、部屋は比較的綺麗だ。床に物は落ちていない。デスクの上も整理されている。技術書も本棚に並んでいる。窓を開けて空気を入れ替える習慣もついた。カーテンも開いていて、部屋の中は明るい。30歳のエンジニア、独身。在宅勤務という働き方は自由をくれたはずなのに、気づけば自分は4畳半の部屋の中で完結した生活を送っている。仕事もする。プログラミングもする。読書もする。ブログも書く。趣味もある。孤独は嫌いではない。むしろ好きだ。一人で考える時間、一人でコードを書く時間、一人で本を読む時間。誰にも邪魔されず、自分のペースで物事に向き合える時間。これは孤独であって、寂しさではない。寂しいと孤独は別物だ。孤独は選べるが、寂しさは選べない。でも私生活がぐちゃぐちゃになってしまうと、自分のプライベートも引きずられて悪くなる。掃除をしなくなる。自炊をしなくなる。身だしなみが雑になる。運動をしなくなる。風呂に入らなくなる。これらが崩れ始めると、部屋は散らかり、仕事も集中できなくなり、趣味も楽しめなくなり、選んだはずの孤独が、望まない寂しさに変わっていく。掃除は、精神の指標になる。部屋を見れば、今の自分の精神状態が分かる。乱れている時は心も乱れている。整っている時は心も整っている。結局、最も重要なのは燃え尽きずに続けることで、そのために必要なのは自分を大切に扱うことで、その最も基本的な実践が掃除なのではないか。この記事は、そんな仮説を自分自身で検証するために書いている。掃除とは何か。なぜ自分は掃除ができなくなるのか。そして掃除することで何が変わるのか。表面的な整理整頓の話ではなく、もっと根本的な、自分をどう扱うかという話だ。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。掃除できない理由は全て言い訳だ「忙しいから掃除できない」。でも本当にそうか？毎日Twitterを見て、YouTubeのショート動画を延々と見ている。気づけば一時間、二時間が過ぎている。つまり、時間がないのではない。掃除を優先していないだけだ。「疲れているから」という言い訳もある。でも実は、散らかった部屋で過ごしていることが疲れの原因かもしれない。視界の隅に常にゴミや散らかったものが入ってきて、それが無意識のストレスになっている。朝起きたときにすでに憂鬱で、仕事を始める前からエネルギーが削がれている。だから疲れる。そして疲れているから掃除しない。この悪循環。「どうせすぐ散らかるから」という諦めもある。以前掃除したけど三日後には元通りだった。でもなぜか。綺麗にした後、何も仕組みを変えていなかったからだ。服を脱いだら床に置く習慣、ゴミが出たらデスクに置く習慣、本を読んだら床に積む習慣。掃除をしたというより、一時的に物を移動させただけだった。これらの言い訳を並べてみて気づく。どれも本質的な理由ではない。本当の理由はもっと深いところにある。「どうせ自分なんか」という、言葉にならない諦めが。部屋を整えることが心を整えるよく「部屋の乱れは心の乱れ」と言われる。でもこの言葉は因果関係が逆だ。「部屋の乱れが心を乱す」のだ。そしてもっと正確に言えば「部屋を整えることが心を整える」。心という曖昧なものを直接コントロールすることは難しい。でも部屋という物理的な空間は、手を動かせば変えられる。服をハンガーにかける。ゴミを捨てる。床を拭く。これらは全て、具体的で、実行可能で、結果が目に見える行動だ。そしてこれらの行動が、不思議なことに心に作用する。綺麗な部屋で目覚めると、一日の始まりが違う。整理されたデスクで仕事をすると、思考がクリアになる。物が少ない空間にいると、頭の中も軽くなる。部屋を整えることは、心を整えるための、最も具体的で確実な方法なのだ。掃除は自分への態度を訓練する修行だ掃除は単に「清潔にする」ための行動だと思われがちだ。でも実は、もっと深い意味を持っている。自分をどう扱うかを、身体に教えている訓練なのだ。掃除とは、「自分の空間を整える力が自分にある」と確認することだ。散らかった部屋を見て「どうせ自分には無理だ」と諦めるのではなく、一つずつ片付けていく。床に落ちている服を拾う。ゴミを捨てる。デスクを拭く。この行為を通じて「自分には変える力がある」と身体で理解する。これは掃除だけではない。自炊なら「自分のために手を動かす価値がある」と身体が覚えること。身だしなみを整えるのは「私は丁寧に扱っていい存在だ」と身体に教えること。運動することは「自分の身体に投資する価値がある」と確認すること。風呂に入ることは「私は清潔でいていい存在だ」と身体に教えること。しかし、その中でも掃除は最も基本的で、最も効果が目に見えやすい実践だ。「どうせ自分なんか」と思って放っておく時間が続くと、それらの行為がどうしても億劫に感じて、身体は「私は放っておかれて当然なんだ」と学んでしまう。逆に言えば、少しずつでも、適当でも、掃除をしていくことで、「自分は守られていい」「手をかけられていい」と身体が再び信じ始める。これは精神論ではない。実際に起きることだ。部屋を掃除した日の夜、なぜか少しだけ自己肯定感が上がる。掃除は、自分への態度を訓練する修行なのだ。放置のサイクルと手入れのサイクル放置のサイクル朝起きる。部屋が汚い。気分が重い。でも掃除する気力がない。「今日は忙しいから」と自分に言い訳をする。朝食も作らない。シャワーも浴びない。適当な服を着る。仕事を始める。集中できない。視界の隅にゴミが見える。気が散る。効率が落ちる。疲れる。夜になる。もっと疲れている。掃除なんてできない。自炊もめんどくさい。風呂に入るのもめんどくさい。運動なんてもってのほか。「明日やろう」と思う。眠る。次の日も同じ。部屋は昨日より汚い。服がもう一枚増えている。ゴミがもう一つ増えている。気分はもっと重い。でも何もする気力はもっとない。そしてまた「明日やろう」と思う。一週間後、すべてが荒れ果てている。部屋は散らかり、床はほとんど見えない。デスクは物で埋まっている。空気は淀んでいる。そして自分の気持ちも荒れ果てている。「もうどこから手をつけていいか分からない」という諦めが支配している。毎日、放置という行動を通じて、「お前は放っておかれて当然だ」というメッセージを自分自身に送り続けている。手入れのサイクル朝起きる。部屋が綺麗。気持ちがいい。窓を開ける。空気を入れ替える。ベッドを整える。たった一分の作業だが、これだけで一日の始まりが違う。シャワーを浴びる。髪を整える。清潔な服を着る。朝食を作る。簡単なものでいい。温かいご飯。身体が目覚める。仕事を始める。デスクが綺麗だから集中できる。必要なものがすぐ見つかる。思考がクリア。コードがスムーズに書ける。効率が上がる。気持ちがいい。昼休み、食器をすぐ洗う。軽く散歩する。身体を動かす。夜、仕事を終える。運動する日もある。しない日も軽くストレッチする。夕食を作る。自分のために作った温かいご飯。シャワーを浴びる。床に落ちているものを片付ける。ゴミを捨てる。読んだ本を本棚に戻す。合計十分。でもこの十分が、明日の自分を助ける。身体は学習する。「私は手をかけられる存在だ」と。「私の空間は整っていていい」と。「私は価値がある」と。行動が、その人の存在の意味を決める。言葉ではなく、行動が。毎日の小さな選択が、自分をどう扱うかを決めている。規律という美学部屋が散らかっている時の自分は、不思議なことに、あらゆる面が乱れている。時間管理も散らかる。締切ギリギリになって慌てる。生活のあらゆる面は繋がっていて、一つの領域での乱れは、他の領域にも波及する。逆に、部屋を整えている時期の自分は、あらゆる面が整っている。朝、決まった時間に起きられる。約束を守れる。締切を守れる。自分との約束も守れる。そしてこの規律が、自分という存在に秩序をもたらす。美しさとは、日々の規律ある行動から生まれる副産物なのではないか。一つ一つの動作に美を宿すこと。服を畳むときに丁寧に畳む。食器を洗うときに丁寧に洗う。掃除をするときに隅々まで拭く。これらの「めんどくさい」行為が、実は自分を美しくしている。誰も見ていない。在宅勤務だから誰にも会わない。だから適当でいい。そう思って過ごしていると、その「適当さ」が身体に染み込んでいく。でも逆に、誰も見ていなくても、自分のために丁寧に生きる。その選択が、自分を美しくする。掃除は「修行」として捉えるべき実践なのだ。小さく始めるという勇気ある日、決意した。「今日から毎日掃除をする」と。でも夜には忘れていた。三日目には諦めていた。「やっぱり自分には無理だ」と。問題は、始め方が大きすぎたことだ。「毎日掃除をする」というのは、実は途方もなく大きな変化だ。でもある時、試しに小さく始めてみた。「朝起きたら、ベッドを整える。それだけ」。これなら一分もかからない。簡単すぎる。でもこれを続けた。一週間、二週間、一ヶ月。気づけば習慣になっていた。そして不思議なことに、ベッドを整える習慣ができると、他のことも少しずつやりたくなってきた。「どうせベッドを整えるなら、カーテンも開けよう」「どうせカーテンを開けるなら、窓も開けよう」「どうせ窓を開けるなら、ゴミも捨てよう」。小さな一歩が、次の一歩を呼ぶ。完璧を求めて何もしないより、不完全でも小さく始める方が、ずっと前に進める。一日五分の掃除と、週に一回の大掃除、どちらが効果的か。前者だ。なぜなら習慣になるから。小さく始めることは、実は最も大きな勇気を必要とする。なぜなら、小さすぎて効果がないように感じるから。「たったこれだけで意味があるのか」という疑念と戦わなければならない。でも意味はある。確実にある。身体は小さな変化を記憶する。そして小さな変化の積み重ねが、大きな変化になる。おわりにこの記事を書きながら、自分の部屋を見回している。今、部屋は比較的綺麗だ。床に物はほとんど落ちていない。デスクの上も整理されている。窓を開けて空気を入れ替える習慣もついた。これらの小さな習慣が、気持ちを支えている。仕事にも集中できる。コードを書くのも、ブログを書くのも、本を読むのも楽しい。掃除は、精神の指標になる。今、部屋が比較的綺麗なのは、今の精神状態が比較的安定しているということだ。でも油断すると、すぐに乱れる。だから毎日少しずつ手をかけ続ける。才能があっても燃え尽きたら意味がない。理解が速くても続かなければ意味がない。結局、長く続けた人が、最も遠くまで行く。そして長く続けるために必要なのは、派手なスキルでも高度な知識でもなく、自分を丁寧に扱う日々の習慣だ。掃除は単なる家事ではない。自分への態度を訓練する修行であり、自分という存在をどう扱うかを身体に教える実践だ。そして何より、燃え尽きないための、最も基本的な自己防衛の手段なのだ。在宅勤務で過ごす30歳の自分にとって、掃除は生き延びるための技術になった。孤独は好きだ。一人で考える時間、一人でコードを書く時間、一人で本を読む時間。誰にも邪魔されない自由。でもその孤独を愛するためには、まず自分の空間を整える必要があった。部屋を整えることで、心を整える。空間に秩序をもたらすことで、人生に秩序をもたらす。そして集中して仕事ができる。コードが書ける。ブログが書ける。本が読める。選んだ孤独を、寂しさに侵食されずに生きられる。自分を大切にするということ。それは掃除をすること、自炊をすること、身だしなみを整えること、運動をすること、風呂に入ること。これらすべてが大切だ。でもその第一歩が、掃除なのだ。「どうせ自分なんか」という声が聞こえたら、まず床に落ちている服を一枚拾う。ゴミを一つ捨てる。デスクを一度拭く。たったそれだけでいい。その小さな行動が、「自分は手をかけられていい」というメッセージを、自分自身に送る。そして身体がそれを覚える。少しずつ、少しずつ、「自分は大切にされていい存在だ」と信じ始める。完璧を目指す必要はない。毎日完璧に掃除する必要もない。ただ、少しずつでも、適当でも、自分に手をかけ続けること。それが掃除の本質であり、同時に自分を整えることの本質であり、そして燃え尽きずに続けるための、最も確実な方法なのだ。技術は大切だ。知識も大切だ。仕事も大切だ。プログラミングも大切だ。読書も大切だ。ブログも大切だ。趣味も大切だ。孤独を愛することも大切だ。でも最も大切なのは、自分を大切にすることだ。そしてその第一歩が、自分の部屋を掃除することなのかもしれない。おい、部屋を掃除しろ。それは命令ではなく、自分自身への、静かな呼びかけだ。長く続けるために。燃え尽きないために。そして、自分を大切にするために。利他・ケア・傷の倫理学作者:近内悠太晶文社Amazonカウンセリングとは何か　変化するということ (講談社現代新書)作者:東畑開人講談社Amazon

おい、部屋を掃除しろ

言葉にしない限り、『なんか』は永遠に巨大な壁であり続ける

近すぎず、遠すぎず - コードの結合度とちょうどいい距離の測り方

構造的類似性を捉える技術 - similarity-rsで学ぶAST-basedコード解析の実装

ソフトウェアエンジニアにおける才能という幻想、あるいは成長を阻む最大の敵について

技術力に優劣はある(「技術力に優劣はない」を読んで)

cargo-chefがRustのDockerビルドを高速化する話

RustのDockerfile、2025年はこれでいこう

cargo-watch、やめるってよRustを書いてると、気づくんですよね。保存ボタンを押すたび、手動でcargo checkとかcargo testとか叩いてる自分に。「あれ、俺って原始人だっけ？」みたいな気持ちになる。そこで救世主として現れたのがcargo-watchだったわけです。過去形。github.comそう、cargo-watchはもうメンテされてないんです。引退しちゃった。ここで一旦、真面目な話を。10年以上もcargo-watchとwatchexecっていうOSSプロジェクトを守り続けてきたFélix Saparelliさんに、心から敬意と感謝を。あなたのおかげで、世界中の無数のRust開発者が「あ、これ便利じゃん」って生産性爆上げできたんです。本当にありがとうございました。で、公式READMEには作者本人がこう書き残してる。"It's time to let it go. Use Bacon. Remember Cargo Watch."なんかもう、エモすぎません？10年以上続いたプロジェクトが、バトンを次世代に渡して静かに去っていく感じ。その後継者がbacon。そして汎用性の塊みたいなwatchexec。ベーコンって名前、朝ごはん感あるけど、これが本当にすごいんですよ。というわけでこの記事では、Rust開発で使えるファイル監視ツールについて解説していきます。cargo-watchロス、今日で終わりにしましょう。baconって何？baconは、Rust専用に作られたバックグラウンドコードチェッカーです。エディタの隣で動かしておくと、ファイルを保存するたびに自動でコンパイルチェックを走らせて、エラーや警告をリアルタイムで表示してくれます。github.comcargo-watchとの違いcargo-watchの作者が「baconこそが自分の理想だった」と語っているほど、baconは進化しています。TUIで見やすい - エラーが警告より先に表示され、スクロール不要キーボード操作 - tでテスト、cでClippy、dでドキュメントと一瞬で切り替え小さい画面でも快適 - ターミナルのサイズに合わせて表示を最適化Rust Analyzerと競合しない - 開発体験がスムーズインストール# 基本インストールcargo install --locked bacon# オプション機能も入れる（クリップボード、サウンド）cargo install --locked bacon --features "clipboard sound"基本的な使い方プロジェクトのルートでbaconを起動するだけ。cd your-rust-projectbaconデフォルトではcargo checkが走ります。ファイルを保存すると自動で再チェック。主要なキーボードショートカットbaconの真価はキーボードショートカットにあります。t - テスト実行に切り替えc - Clippyに切り替えd - ドキュメントをブラウザで開くf - テスト失敗時、そのテストだけに絞り込みEsc - 前のジョブに戻るCtrl+j - すべてのジョブ一覧を表示h - ヘルプ表示q - 終了特定のジョブで起動# テストを監視bacon test# Clippyを監視bacon clippy# 厳格なClippyルール（pedantic）bacon pedantic# 高速テストランナー（nextest）bacon nextest# すべてのターゲットをチェックbacon check-all# 特定のジョブを指定bacon --job my-custom-jobbacon.toml で設定をカスタマイズプロジェクトに合わせてジョブを定義できます。# 設定ファイルを生成bacon --init設定例# bacon.toml# Windows向けのチェック[jobs.check-win]command = ["cargo", "check", "--target", "x86_64-pc-windows-gnu"]# 厳しめのClippy[jobs.clippy-strict]command = [    "cargo", "clippy", "--",    "-D", "warnings",    "-A", "clippy::collapsible_if",]need_stdout = false# サンプルをチェック[jobs.check-examples]command = ["cargo", "check", "--examples", "--color", "always"]watch = ["examples"]  # srcは自動で監視される# 実行ジョブ[jobs.run]command = ["cargo", "run"]allow_warnings = trueneed_stdout = true# キーバインディングのカスタマイズ[keybindings]shift-c = "job:clippy-strict"r = "job:run"設定しておいてよいことドキュメントを素早く確認[jobs.doc-open]command = ["cargo", "doc", "--no-deps", "--open"]need_stdout = falseon_success = "back"  # ドキュメントが開いたら前のジョブに戻る長時間実行するアプリケーション[jobs.server]command = ["cargo", "run"]allow_warnings = trueneed_stdout = truebackground = falseon_change_strategy = "kill_then_restart"watchexecとの使い分けbaconはRust専用ですが、watchexecは汎用的なファイル監視ツールです。github.comwatchexecを使うべき場合# インストールcargo install watchexec-cli# 基本的な使い方watchexec --restart cargo run# 特定の拡張子だけ監視watchexec -e rs,toml cargo test# デバウンス設定watchexec -d 2000 cargo checkwatchexecが向いているケース：- Rust以外の言語やツール- シェルスクリプトの実行- rsyncなどの同期処理- より細かい制御が必要な場合# 例：TypeScriptのビルドwatchexec -e ts,tsx npm run build# 例：ファイル同期watchexec -w src -- rsync -avhP ./src/ ./backup/実践的なワークフロー開発時のセットアップターミナルを分割左：Vim/Neovim右上：bacon右下：通常のシェル私はWarpを使ってペイン分割している。baconの起動bacon  # デフォルトでcheckが走るコードを書く保存すると自動でチェックエラーがあれば即座に表示エラーが消えたらClippyの警告が見えるテストを書くtキーでテストモードに切り替え失敗したらfで絞り込み修正したらEscで全テストに戻る最終チェックcキーでClippyの提案を確認コード品質を向上ちょっとしたTipsシェルエイリアスで効率化頻繁に使うコマンドをエイリアス化すると便利です。# ~/.zshrc または ~/.bashrc に追加alias bac='bacon'alias bacc='bacon clippy'alias bact='bacon test'alias bacp='bacon pedantic'watchexecで複数パスを監視# srcとtestsディレクトリの.rsと.tomlファイルを監視watchexec -e rs,toml -w src -w tests -- cargo testVim/Neovimとの連携nvim-bacon プラグインbaconの診断結果をNeovimに統合するプラグインがあります。github.com" lazy.nvim の場合{  'Canop/nvim-bacon',  config = function()    require('bacon').setup()  end}主な機能は以下の通り。エラー箇所へのジャンプQuickfixへの統合:Bacon コマンドでbaconを起動:BaconLoad で診断結果を読み込み補足：VS Code向けVS Codeユーザーの場合は、bacon-lsというLanguage Serverが利用可能です。まとめcargo-watchの時代は終わりました。でも、より良いツールが生まれています。こう使い分けよう：Rust開発 → bacon一択TUIが快適キーボードだけで完結設定ファイルで柔軟にカスタマイズそれ以外 → watchexec汎用的に使えるシンプルで強力シェルスクリプトとの相性抜群baconを知らずにRustを書いていた人は、今すぐ試してください。開発体験が一段階レベルアップします。cargo install --locked baconcd your-projectbaconたったこれだけ。あとはコードを書くだけです。参考リンク：- bacon公式サイト- watchexec GitHub- cargo-watch（アーカイブ済み）

baconを知らずにRust書いてた

2025年9月30日（火）、「バイブコーディングもくもく会 #03」というイベントで登壇することになった。https://aimokumoku.connpass.com/event/368935/正直に言うと、このイベントがどんな空気感なのか、まだ全然掴めていない。ゆるい感じなのか、ガチな感じなのか。笑いを取りに行くべきなのか、真面目にやるべきなのか。そういう「場の空気」みたいなものが事前に分からないのは、けっこう怖い。だから、とりあえず色々なパターンを想定して準備している。要するに、どんな状況になっても対応できるように、という保険をかけまくっているのだ。我ながら、慎重すぎるかもしれない。ブログとGithubはこちら。https://syu-m-5151.hatenablog.com/https://github.com/nwiizo一応、置いておく。見られるのは恥ずかしいけど、見られないのも寂しい。そういう矛盾した感情を抱えながら、当日を迎えることになりそうだ。Marp の資料はこちらです。https://github.com/nwiizo/3shake-marp-templates/blob/main/slides/2025/vibe-coding-continuous-deployment.md

バイブコーディングと継続的デプロイメント

2025年9月10日（水）、「Rustの現場に学ぶ〜Webアプリの裏側からOS、人工衛星まで〜」というイベントで登壇させていただきます。https://findy.connpass.com/event/359456/他の登壇者の話が聞きたすぎるけど調整能力の圧倒的な不足で登壇したらすぐに帰らなければなりません。今回の発表内容のベースとなったのはこちらのブログです。- 「RustのWebアプリケーションにオブザーバビリティを実装するインフラエンジニアのための入門ガイド」

Webアプリケーションにオブザーバビリティを実装するRust入門ガイド

2025年9月5日（金）、台風接近という悪天候の中でしたが、「CNCJ: コーディングエージェント × セキュリティ ミートアップ」に登壇させていただきました。天候の影響で現地参加が難しい方も多い中、オンラインでの参加や配信により、多くの方にお聞きいただくことができました。### 📍 イベント情報- 開催日: 2025年9月5日（金）- イベント詳細: CNCFコミュニティページ### 📹 録画・資料公開予定- 録画: CNCJのYouTubeチャンネルにて後日公開予定- 発表資料: Connpassページに掲載予定### 📝 関連ブログ今回の発表内容のベースとなった考え方については、こちらのブログ記事でも詳しく解説しています：- 「2025年夏 AIエージェントシステムに対する考え方」台風の中、ご参加・ご視聴いただいた皆様、ありがとうございました。

2025年夏 コーディングエージェントを統べる者

「 転職したらMCPサーバーだった件」というタイトルで登壇したことがある。本日は「JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ」というなんとなく強そうなイベントで登壇しました。🔍 イベント詳細:- イベント名: JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ- 公式URL: https://jawsug-sre.connpass.com/event/358781/- ハッシュタグ: https://x.com/search?q=%23jawsug_sre&f=live- 参考資料①: https://speakerdeck.com/nwiizo/zhuan-zhi-sitaramcpsabadatutajian

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

諸君、聞かれよ。本日、私は「女オタ生成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 

僕が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

本日、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サーバーだった件

本日、「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基盤構築の可能性と実践的ガードレールの敷設について

本日、「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

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