nwiizo

AI時代の異常系テストについて考える

おい、戦略を語れ

2025年版 PDE（Personal Development Environment）のすすめ：自分だけの刀を打つ開発環境構築

はじめに正直に言うと、私はキャリアの序盤、破滅的な文章を書く人間だった。誰が読むのか考えていない文章を書きまくっていた。学生時代に読書感想文のコンクールで優勝したこともなければ、文章を褒められた経験もほとんどない。それでも書き続けて、今はこうして登壇の機会をいただけるようになった。2025年12月5日、Forkwell Communityのイベント「おい、テックブログを書け」で登壇しました。forkwell.connpass.com発表資料はこちらです。 speakerdeck.com「おい、」シリーズがイベントになった私は「おい、」シリーズというブログを書いている。元々は書籍用に書き溜めていた文章を公開する場所として始めたものだが、ありがたいことに多くの反響をいただいている。syu-m-5151.hatenablog.com今回のイベントは、Forkwellのかわまたさんにお誘いいただいて実現した。かわまたさんには以前も「転職したらMCPサーバーだった件」というイベントでお声がけいただいた。 speakerdeck.com貴重な登壇の機会をいただいているのにこんなことを言うのはあれだが、結構変なことをさせてくれる。変な人だ（褒めている）。自分もこれぐらいふざけた企画をできるくらい組織で信用されたい。とめちゃくちゃに思う。こうした機会をもらえるのは、発信を続けてきたからだ。私よりエンジニアとしても語り手や書き手としても才能のある人はたくさんいる。でも、その才能を発揮せずに誰からも見つからないままでいる人も多い。なぜ発信しないのか。まず、炎上が怖い。間違ったことを書いたら叩かれるんじゃないか。知識不足を晒して恥をかくんじゃないか。そう思うと、公開ボタンを押す手が止まる。次に、時間がない。業務が終わってから記事を書くのは大変だ。言いたいことを整理して、文章にまとめて、推敲して。そこまでの気力が残っていない日も多い。組織の問題もある。評価制度が発信を評価しない会社では、ブログを書いても給料は上がらない。それどころか「そんな暇があったらコードを書け」と言われることもある。発信は「業務外の趣味」として扱われる。こうした障壁は確かに存在する。でも、それらすべてを解決してから書き始める必要はない。まず書いてみることなら、今日からでもできる。炎上が怖いなら、小さな技術メモから始めればいい。時間がないなら、完璧を目指さず短い記事でいい。組織が変わらなくても、自分のブログは自分で始められる。書き始めるとき、人は出発点ばかり気にしがちだ。「自分には文章の才能がない」「最初からうまく書ける人には敵わない」──そう思って発信をためらう人がいる。でも、書く力は後天的になんとかなる。出発点が低くても、続けていれば追いつける。追い越せることだってある。見てくれた皆さんには、発信やアウトプットを通じて才能を発揮し、それに見合った評価や機会を得てほしい。そう思って今回の登壇資料を作った。書くときに大切にしていること資料では「どう書くか」の型を紹介したが、その前提にある考え方も書いておきたい。私が意識しているのは3つある。「なぜ」を問うこと、「変化」を描くこと、「ゆらぎ」を残すこと。この3つは独立しているようで、実は重なり合っているので紹介していきたい。「なぜ」を問い続ける単なる事実や記録ではなく、理由や背景を深掘りする姿勢が大切だ。たとえば「Aを使った」だけでなく「なぜAを選んだのか」「なぜBではダメだったのか」を書く。読者が最も知りたいのは「なぜ」の部分だ。選択の理由を言語化することで、自分の理解も深まる。ところが、技術ブログでありがちなのは、手順だけを淡々と書いてしまうこと。「この設定を入れます」「このコマンドを実行します」──それだけでは公式ドキュメントの劣化コピーになる。「なぜこの設定なのか」「なぜこの順番なのか」「なぜ他の方法ではダメだったのか」を書くことで、初めて読む価値が生まれる。「なぜ？」の部分が業務事情に抵触する場合もある。具体的な数値や社内の意思決定プロセスは書けない。そういうときは、一般的な観点に置き換える工夫をすればいい。「弊社の事情で」ではなく「〇〇のようなケースでは」と書く。具体的な比較ができないなら「一般的にAとBにはこういう違いがある」と整理する。工夫次第で、機密を守りながら「なぜ」を伝える方法はいくらでもある。「なぜ？」を問い続けると、自分の理解の浅さに気づくこともある。それでいい。書くことは、自分の理解を試す行為でもある。書けないということは、わかっていないということだ。その気づきこそが成長の起点になる。「行動」と「変化」のあるストーリーにする「なぜ」を問い続けていると、自然と「変化」が見えてくる。最初はこう思っていた、でも調べていくうちにこう変わった。その変化こそが、記事の核になる。人は変化の物語に心を動かされる。問題に出会い、試行錯誤し、解決に至る。その過程で自分の理解がどう変わったか。「わからない」から「わかった」への変化こそが、読者にとって価値のある情報だ。だから、静的な情報の羅列は退屈だ。「Kubernetesのリソース制限には以下の種類があります」と書くより、「OOMKilledで3時間溶かした。原因を調べていくうちに、リソース制限の仕組みが腹落ちした」と書く方が読まれる。同じ情報でも、変化の物語として語ることで、読者は追体験できる。行動と変化を意識すると、自然と時系列が生まれる。最初に何を思っていたか、何をしたか、何が起きたか、どう理解が変わったか。この流れがあるだけで、記事は格段に読みやすくなる。そして、変化には「失敗」も含まれる。むしろ失敗からの学びの方が読者には刺さる。「最初からうまくいきました」という記事より、「こう考えて失敗し、別のアプローチで解決した」という記事の方が、読者の記憶に残る。失敗を隠さず、そこから何を学んだかを書くことで、記事に深みが出る。「気持ちのゆらぎ」を素直に残す失敗を書くとき、その時の迷いや不安も一緒に残しておくといい。整いすぎた文章は、かえって心に響かない。なぜか。人間味が消えてしまうからだ。「最初は〇〇だと思っていたけど、実際は違った」「正直、これでいいのか迷った」「ここは今でも自信がない」──そうした揺れを正直に書くことで、読者との距離が縮まる。完璧を装う必要はない。技術ブログを書くとき、つい「わかっている人」として振る舞いたくなる。でも、読者が共感するのは「わかっていなかった人がわかるようになる過程」だ。迷い、間違え、遠回りした経験こそが、読者にとって価値がある。気持ちのゆらぎを残すことには、もう1つ意味がある。後から読み返したとき、その時の自分に出会える。「あの頃はこんなことで悩んでいたのか」と思えるのは、整いすぎていない文章だからこそだ。ゆらぎを残すことに抵抗がある人もいるだろう。弱く見えるのではないか、と。でも私の考えは違う。ゆらぎを残すことは、弱さを見せることではない。誠実さを見せることだ。「これが正解です」と断言する記事より、「私はこう考えてこうした、でも別の方法もあるかもしれない」と書く記事の方が、読者は信頼する。技術の世界に絶対の正解は少ない。その不確かさに正直であることが、かえって記事の信頼性を高める。おわりに技術ブログを書くことは、自分の成長のためだ。「なぜ？」を問い続け、変化の物語として語り、気持ちのゆらぎを素直に残す。結果として、それが誰かを救うこともあるかもしれない。私自身がそうだった。冒頭で書いたように、私は「破滅的な文章を書く人間」だった。それでも書き続けて、今がある。苦手から逃げても、その先にあるのはまた別の苦手だ「文章が苦手だから書かない」「人前で話すのが苦手だから発信しない」──そう言って避け続ける人は多い。気持ちはわかる。苦手なことに向き合うのは辛い。できない自分を直視するのは苦しい。でも、逃げた先に何があるだろうか。苦手なことを避け続けても、人生から苦手がなくなるわけではない。文章から逃げれば、別の場面でまた「苦手」にぶつかる。逃げ続けた結果、選択肢がどんどん狭まっていく。気づいたときには、逃げ場すらなくなっている。いま苦手であることと、将来成果を出せるかどうかには、おそらく何の因果関係もない。初期能力が高い人が最終的に優れた成果を出すとは限らない。むしろ、最初から得意な人は壁にぶつかったとき折れやすい。苦手だった人の方が、泥臭く続ける力を持っていたりする。私は明らかに後者だった。最初からうまく書けたわけではない。読み返すと恥ずかしい文章をたくさん書いた。それでも書き続けた結果、今がある。出発点の低さは、到達点を決めない。「自分探し」という名の逃避「自分に向いていることを見つければ、苦労せずに成果が出る」──そんな幻想がある。「自分探し」という言葉は、その幻想を正当化する。本当の自分を見つければ、努力なしに輝ける場所がある。そう信じたい気持ちはわかる。でも、多くの場合それは苦手や欠損から逃れるための言い訳でしかない。向いていないから別のことを探す。それも向いていないから、また別のことを探す。その繰り返しで時間だけが過ぎていく。本当の自分は、探すものではない。目の前のことに向き合い、苦手なことに取り組み続ける中で、少しずつ形作られていくものだ。「これが自分だ」と思えるようになるのは、何かをやり抜いた後だ。やる前からわかるものではない。向いていることを探すより、目の前のことに向き合う方が、よほど確実に成長できる。向いているかどうかは、やってみなければわからない。やり続けてみなければわからない。最初の苦手意識だけで判断するのは、あまりに早すぎる。正しい方向に努力すれば、必ず上達するとはいえ、漫然と続けるだけでは上達しない。書くことと、うまくなることは、自動的にはつながらない。読者の反応を見る。うまい人の文章を読んで、何が違うのか考える。自分の過去記事を読み返して、恥ずかしくなる。そうやってフィードバックを受け取り、意識的に改善しようとすることで、少しずつ書けるようになる。大事なのは、フィードバックループを回すことだ。書く→反応を見る→改善点を見つける→また書く。このサイクルを回し続ければ、必ず上達する。才能の有無ではなく、このループを回し続けられるかどうかが、成長を決める。こう書くと「それは書けた側の言い分だ」と思う人もいるかもしれない。生存者バイアスじゃないか、と。確かにそうだ。書けなかった人の声は届かない。でも、だからこそ書けた側が伝えるしかない。書けないと思っている人、文章に自信がない人に、「それでも書ける」と伝えられるのは、同じ場所から歩いてきた人間だけだ。だから、今日からでも始めてほしい。まずは今日学んだこと、ハマったこと、気づいたことを3行だけ書いてみる。下書きのまま放置している記事があるなら、不完全でもいいから公開してみる。完璧を待っていたら、いつまでも始まらない。苦手だと思っていることほど、始めてしまえば案外なんとかなる。登壇・技術顧問のご依頼について登壇依頼はいつでも募集しています。今回のようなちょっと変わった企画でも大歓迎です。気軽にDMしてください。また、技術顧問業もやっています。SRE、プラットフォームエンジニアリング、組織づくりなど、雑多な質問でもお待ちしております。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。

『おい、テックブログを書け』というタイトルで登壇しました

専門家は話さないですよ(『専門家が「力」をセーブせずに全力で専門性を振り回してもリスペクトされる組織をつくりたい』を読んで)

2025年 俺が愛した本たち 技術書編

2025年版 私がAIエージェントと協働しながら集中する方法

実力とは“最悪の自分”が決める

この記事は、whywaita Advent Calendar 2025 8日目のエントリ記事です。whywaita Advent Calendar 10周年ということで、自分もwhywaitaとの出会いと10年という節目を掛けて何か書きたいと考えたのですが、うまいネタが思いつかず。とはいえ、whywaitaと出会ったきっかけがお祭り的な技術イベントだったので、今回は技術イベントの「お祭り性」について語っていきます。思い返すと、技術コミュニティとの出会いは、いつもお祭りのようでした。見知らぬ人と技術の話で盛り上がり、気づいたらとんでもない深い時間になっていた懇親会。準備段階から当日まで、ワクワクしながら作り上げた勉強会。あの空気感こそが、私をエンジニアとして成長させてくれた原動力でもありました。そんな私が最近読んで、考えさせられた記事があります。はじめにSakutaroさんが書かれた「技術広報をなめるな」を読みました。note.comSakutaroさんの主張をこの記事で使うために要約すると、技術広報とは「技術に関する情報流通を最適化すること」であり、採用やブランディングにじわじわ効いてくる組織の筋肉である、ということです。片手間でやるものではなく、専門性を持って取り組むべき重要な機能だと。その主張には100%同意します。技術広報を軽視する組織への警鐘として、価値のある記事でした。詳しくは読んで下さい。ただ、読み終わったあと、ひとつ気になることがありました。「なめるな」と言われて、真面目に取り組んだ人は、どうなるだろう。技術広報の重要性を理解した。だから本気で取り組んだ。毎週ブログを書き、登壇の機会を作り、勉強会を企画した。でも、半年後、1年後、その人はまだ続けているだろうか。私が見てきた現実では、真面目に取り組んだ人ほど、燃え尽きていく。「技術広報は大事だ」と理解しているからこそ、手を抜けない。手を抜けないから、疲弊する。疲弊するから、続かない。続かないから、また新しい誰かが「大事だから」と引き継いで、同じサイクルを繰り返す。ここで断っておくと、私は専任のDevRelや技術広報をやっていたわけではありません。エンジニアとしてブログを書いたり、登壇したり、勉強会を企画したり、そういう活動に参加してきた側です。だから以下は、「現場で技術広報に関わってきたエンジニア」としての個人的な意見です。Sakutaroさんへの反論や批判ではなく、同じテーマを別の角度から眺めてみた、という試みです。Sakutaroさんが「技術広報の重要性」を語ったのなら、私は「技術広報の持続可能性」を語りたい。Sakutaroさんが「なめるな」と言ったのなら、私は「ちゃんとなめてやれ」と言いたい。「なめる」というのは、軽視することではありません。肩の力を抜いて、それでも真剣に向き合うこと。重く構えすぎず、軽やかに、本気で楽しむこと。そういう姿勢を指しています。この記事で言いたいのは、技術広報を「お祭り」として捉え直すことで、どう持続可能な形に設計できるか、という話です。「技術広報を続けられない」のは、個人の努力不足なのか技術広報が続かない。ブログの更新が止まる。勉強会の開催頻度が落ちる。登壇者が見つからない。こうした現象を見たとき、私たちはつい「担当者の努力が足りない」「モチベーションの問題だ」と考えがちです。でも、本当にそうでしょうか。私が見てきた限り、技術広報に関わる人は真面目な人が多い。「会社のためになる」「エンジニアの成長につながる」と信じているからこそ、時間を割いて取り組んでいる。努力が足りないのではなく、むしろ、努力しすぎて燃え尽きている。つまり、個人の努力ではなく、構造に原因があるのではないか。技術広報を「重要な業務」として位置づけるほど、プレッシャーは増す。「会社の顔としてふさわしい記事を」「PVやシェア数で成果を示さないと」「毎月コンスタントに発信を」。こうした期待は、真面目な人ほど重く受け止める。結果として、技術広報は「楽しいからやる」ものではなく「やらなければならない」ものになる。義務感で動く活動は、長くは続きません。だから私は、技術広報を「お祭り」として捉え直すことを提案したい。技術広報を「お祭り」として捉えたとき、何が変わるのか「お祭り」と「業務」の違いは何か。業務には、目標がある。KPIがある。期限がある。評価がある。達成できなければ、失敗になる。お祭りには、もちろん準備や段取りがある。でも、本質は違う。非日常性があって、ワクワクして、参加は自由で、失敗しても笑って済む。みんなで作り上げる。終わったあとに「楽しかったね」と言い合える。思い出してみてください。あなたが「楽しかった」と感じた技術イベントには、何がありましたか。KPIはなかったはずです。評価もなかった。ただ、技術の好きな人たちが集まって、ワイワイやっていた。それだけで、あの場は価値があった。技術広報を「業務」として捉えると、タスクになり、KPIになり、疲弊の原因になります。でも「お祭り」として捉えると、楽しみになり、創造性の源泉になり、持続可能な活動になる。もちろん、会社という組織なのでKPIは必要です。数字で語らないと理解されないこともある。大人ですから、建前として必要なものは必要です。でも本音の部分では、お祭りなんです。Sakutaroさんは技術広報を「技術に関する情報流通を最適化すること」と定義しました。私はその定義に異論はありません。ただ「情報流通の最適化」という言葉は正確ですが、人を動かす力は弱い。「今月の情報流通を最適化しよう」と言われても、イメージが湧かない。でも「お祭りを企画して盛り上げよう」と言い換えると、途端にイメージが湧きます。人は「最適化」という目標には動きにくいけど、「お祭り」という体験には参加したがるんです。そして面白いことに、良いお祭りを企画しようとすると、自然と「情報流通の最適化」が達成されます。読みたくなるブログは情報が届く。参加したくなる勉強会は知見が共有される。面白いカンファレンスブースはブランドが伝わる。お祭りが楽しいのは、予定調和じゃないからです。神輿が予想外の方向に進んだり、知らない人と急に仲良くなったり、思いもよらない出来事が起きる。その「意外性」がお祭りの醍醐味です。技術広報も同じで、完璧に計画されたブログより、思いつきで書いた記事がバズることもある。意外性こそが人の心を動かします。でも、意外性は余裕がないと生まれません。タスクに追われている人に、遊び心は出てこない。「やらなきゃいけない」という義務感からは、「やってみたら面白かった」という発見は生まれない。だから、技術広報には「精神的な遊び」が必要です。お祭りを「業務」として100%真面目にやると、それはもはやお祭りではなくなります。参加の形は、ひとつじゃないお祭りには色んな参加の仕方があります。神輿を担ぐ人もいれば、屋台で焼きそばを売る人もいる。踊る人もいれば、見ているだけの人もいる。写真を撮る人も、SNSで実況する人もいる。ゴミを拾う人も、場所取りをする人もいる。どの参加の仕方も、お祭りの一部です。技術広報も同じです。記事を書く人だけが貢献者ではない。レビューする人も貢献者です。アイデアを出す人も貢献者です。社内で記事をシェアする人も貢献者です。「この前のあの話、ブログにしたら面白そう」と声をかける人も貢献者です。登壇者の練習に付き合う人も貢献者です。「ブログを書いてもらえない」「登壇してもらえない」と悩んでいるなら、視点を変えてみてください。「書いてもらう」「登壇してもらう」以外の参加の形を、用意できているだろうか。神輿を担げる人は限られています。でも、お祭りを楽しむ方法は無数にある。担ぎ手だけがお祭りの参加者ではないんです。「ブログを書いてください」ではなく「先週のSlackでのやり取り、そのままブログにしませんか。私がタイトルと導入書きますよ」。「登壇してください」ではなく「5分のLTでいいので、この前の話をしてくれませんか」。義務ではなく、招待として。「ブログ書いてください」はお願い（義務感）。「ブログ書きませんか」は招待（選択肢）。この違いは大きいんです。あなた自身は、どうでしょうか。技術広報にどんな形でなら、無理なく関われそうですか。「怒られない範囲」は誰が決めているのかお祭りにも「やっていいこと」と「やってはいけないこと」がある。技術広報も同じです。失敗談を書け、人間臭さを出せ、と言われても、リスクが怖い。その懸念は正しいです。だからこそ、「怒られない範囲」を見極める力が必要になります。ただ、その「怒られない範囲」は、誰が決めているのでしょうか。明文化されたルールがあるのか、暗黙の了解なのか。上司が決めているのか、広報部門が決めているのか、法務が決めているのか。あるいは、なんとなく「空気」で決まっているのか。多くの組織では、「怒られない範囲」は明確に定義されていません。だから、発信する側は常に不安を抱えることになる。「これ、出していいのかな」「怒られないかな」。その不安が、発信のハードルを上げている。社内的にはOKだけど、社外的にNGになるケースがあります。「技術的には正しいけど、今その話題は炎上しやすい」という場合です。社外的にはOKだけど、社内的にNGになるケースもあります。「業界では普通の話題だけど、うちの会社ではタブー」という場合です。「怒られない範囲」を見極める能力とは、社内外の文脈を読む力です。これは経験を積むことでしか身につきません。小さく発信して、反応を見て、学んでいく。でも、もし組織として技術広報を続けたいなら、「怒られない範囲」を個人の判断に委ねるのではなく、組織として明確にする努力が必要ではないでしょうか。「ここまではOK」「これはNG」「迷ったらこの人に相談」。そういった指針があるだけで、発信のハードルはぐっと下がります。あなたの組織では、「怒られない範囲」はどのように決まっていますか。誰が決めていますか。それは明文化されていますか。持続可能にするために最後に、どうすれば技術広報を続けられるのか、という話をします。技術広報に関わる人が陥りがちな罠は、自分一人で全部やろうとすることです。ブログの企画、執筆依頼、レビュー、公開作業、SNSでの拡散。全部一人でやると、短期的には回ります。でも、長期的には崩壊します。お祭りは、主催者一人では成立しません。屋台を出す人、演奏する人、ゴミを拾う人、写真を撮る人、SNSで拡散する人。みんなが違う形で参加して、初めてお祭りは盛り上がります。「一人が100やる」のではなく、「10やる人、5やる人、1でも協力してくれる人を探す」これが持続の秘訣です。例えば、こんな工夫ができます。月に1回「ブログネタ出し会」を30分だけ開く。Slackに「こんな話をブログにしたい」と投げるだけのチャンネルを作る。「書けそうな人」ではなく「話が面白かった人」に声をかける。小さな仕組みを作っておくだけで、協力者は見つかりやすくなります。そして、もう1つ大事なこと。人間には波があるということです。10やれる時期もあれば、5しかやれない時期もある。1すらもやれない時期もある。プロジェクトが佳境に入っている時期。体調を崩している時期。家庭の事情がある時期。メンタルが落ちている時期。これは恥ずかしいことでも、甘えでもありません。人間だもの。「去年できたから、今年もできる」という思い込みこそが、燃え尽きの原因なんです。10やれる時は10やる。5しかやれない時は5でいい。やれない時は、休む。大事なのは、この「波」を組織として受け入れられているかどうかです。「先月は3本記事を出したのに、今月は1本もない。どうしたの」というプレッシャーがかかるなら、それは持続可能な仕組みとは言えません。「今月は厳しいので、来月がんばります」と言える文化があるかどうか。あなたのチームでは、パフォーマンスの波を受け入れられていますか。「今は無理」と言える空気がありますか。おわりに冒頭で書いた通り、私とwhywaitaの出会いは、お祭り的な技術イベントでした。あの場には「情報流通の最適化」なんて言葉はなかった。ただ、技術の好きな人たちが集まって、ワイワイやっていただけです。でも、今ならわかります。私がワイワイと参加していたあのイベントの裏側には、真面目に予算を集めてきた人がいた。色んなステークホルダーの合意をまとめてきた人がいた。会場を押さえ、スケジュールを調整し、トラブルに備えていた「ちゃんとした大人」がいた。私はその恩恵を受けて、楽しんでいただけだったんです。10年経って、そのことがようやくわかるようになりました。いずれ自分も、あの「ちゃんとした大人」の側に回らなければならない。恩返しをしなければならない。その自覚はあります。でも、それでも。いや、だからこそ。次の世代の人たちには、お祭り感を味わってほしい。「裏側の苦労」を見せずに、「楽しかったね」と言ってもらえるイベントを作りたい。真面目に準備しながら、参加者には「お祭り」として届ける。それが、私なりの恩返しの形だと思っています。技術広報に関わるすべての人へ。疲れたら、休んでください。無理したら、倒れます。真面目すぎたら、続きません。でも、楽しさだけでも続きません。楽しさと、仕組みと、仲間が必要です。もしあなたが今「何もやれない時期」にいるなら、それでいいんです。休んでください。お祭りは、また元気になってから参加すればいい。技術広報は、あなたがいないと回らないほど脆弱なものであってはいけない。でも、あなたがいると、もっと楽しくなる。それくらいの距離感がちょうどいい。10年前のあの日、技術イベントで会った人と、今もこうしてAdvent Calendarで繋がっている。これこそが、お祭り駆動の技術広報の成果です。どこかのカンファレンスの懇親会で会ったら、お祭りの話をしましょう。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。

技術広報はちゃんとなめてやれ（技術広報をなめるなを読んで）　

おい、類推するな

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個に絞る。それは人間の性質だ。でも、その枠を超えようとすることが、エンジニアとしての本当の成長なのだと、僕は学んだ。

自動選択と成長

おい、内省しろ

おい、冷笑すんな

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

おい、スマホを置け

おい、一つずつやれ

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 の機能でカバーできる点...

nwiizo

AI時代の異常系テストについて考える

おい、戦略を語れ

2025年版 PDE（Personal Development Environment）のすすめ：自分だけの刀を打つ開発環境構築

『おい、テックブログを書け』というタイトルで登壇しました

専門家は話さないですよ(『専門家が「力」をセーブせずに全力で専門性を振り回してもリスペクトされる組織をつくりたい』を読んで)

2025年俺が愛した本たち技術書編

2025年版私がAIエージェントと協働しながら集中する方法

実力とは“最悪の自分”が決める

技術広報はちゃんとなめてやれ（技術広報をなめるなを読んで）

おい、類推するな

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

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

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

おい、努力しろ

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

おい、がんばるな

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

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

おい、本を読め

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

たぶん、読んでない

おい、対話しろ

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

おい、つなげろ

おい、言語化しろ

自動選択と成長

おい、内省しろ

おい、冷笑すんな

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

おい、スマホを置け

おい、一つずつやれ

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

AI時代の異常系テストについて考える

おい、戦略を語れ

2025年版 PDE（Personal Development Environment）のすすめ：自分だけの刀を打つ開発環境構築

『おい、テックブログを書け』というタイトルで登壇しました

専門家は話さないですよ(『専門家が「力」をセーブせずに全力で専門性を振り回してもリスペクトされる組織をつくりたい』を読んで)

2025年 俺が愛した本たち 技術書編

2025年版 私がAIエージェントと協働しながら集中する方法

実力とは“最悪の自分”が決める

技術広報はちゃんとなめてやれ（技術広報をなめるなを読んで）

おい、類推するな

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

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

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

おい、努力しろ

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

おい、がんばるな

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

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

おい、本を読め

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

たぶん、読んでない

おい、対話しろ

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

おい、つなげろ

おい、言語化しろ

自動選択と成長

おい、内省しろ

おい、冷笑すんな

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

おい、スマホを置け

おい、一つずつやれ

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

2025年俺が愛した本たち技術書編

2025年版私がAIエージェントと協働しながら集中する方法

技術広報はちゃんとなめてやれ（技術広報をなめるなを読んで）　