はじめに 私はかつて、自分の技術思想とキャリア戦略が100%正しいと信じて疑いませんでした。そして、それを受け入れない企業、同僚たちが100%間違っていると本気で思っていたのです。 今思えば、それはソフトウェアエンジニアという職業に就いた多くの若い人が陥る、ある種の思春期的な錯覚だったのかもしれません。技術的な正しさを盾に、社会的な配慮を無視し、人間関係の機微を「非論理的」と切り捨てていました(エンジニアの論理的なんて往々にして論理的ではないのに)。 この記事は、かつての私のような「正義のエンジニア」だった自分への懺悔であり、同じ過ちを犯している人たちへの警鐘でもあります。媚びないことと無礼であることの区別もつかないまま、技術的優位性を振りかざしていた—そんな恥ずかしい過去を、今こそ正直に振り返ってみたいと思います。 DD(どっちもどっち)論 「解決できない問題」には理由がある (WPB

はじめに 2025年6月29日、「#女オタ生成AIハッカソン 2025 夏の陣@東京」なる場において、「生成AIで小説を書くためにプロンプトの制約や原則について学ぶ」という題目で登壇させていただく機会を得た。ハヤカワ五味さんからお声がけいただいた時、私の中でエンジニアとしての好奇心が強く刺激された。エンジニアリングの視点から生成AIの本質を解き明かすことで、創作者の皆様に新しい視点を提供できるのではないか。異なる分野の知見を融合させることで、何か面白いことが起きるかもしれない。そんな期待を胸に、私は登壇に臨んだのであった。(これは嘘で前日不安で酒を飲みすぎた⋯。) note.com 実は、プログラミングの世界では既に大きな変革が進行している。Tim O'Reillyが最近発表した「The End of Programming as We Know It」という論考が示すように、AIの登場に

〜日報をサボってしまう人のための解決策〜 日報、めんどくさいよね 正直に言います。日報書くの、めんどくさいですよね。 僕も毎日終業時に「あれ、今日何やったっけ...」ってなって、GitHubでクローズしたIssue探したり、Slackでミーティングの議事録掘り返したり、Jiraのチケット確認したり...。正確に書こうとすると、気づいたら15分とか経ってるんですよね。 しかも、やっと書き終わったと思ったら「あ、そういえば午前中にあのバグ直したの書き忘れた」「レビューで指摘もらった内容も書かなきゃ」みたいなことがしょっちゅう。 正直、この作業が苦痛すぎて、サボっちゃう日もありました。「明日まとめて書けばいいや」って思って、結局3日分まとめて書く羽目になったり...（そして当然、細かいことは忘れてる）。 でも最近、Claude Codeのカスタムslash commandsを使い始めてから、この

はじめに Claude Code でよく同じコメントを打ってませんか？ 「毎回『テスト実行して、lint チェックして、問題なければコミットして』って言うの面倒だな」とか「プロジェクトごとに決まった手順があるんだけど、毎回説明するのダルい」とか思ったことないですか？ そんなあなたに朗報です。 Claude Code にはカスタムスラッシュコマンドという機能があって、よく使うプロンプトをコマンド化できるんです。しかも設定は超簡単。Markdownファイルを置くだけ。手順書やMakefileが自然言語で書ける時代ですね⋯。 docs.anthropic.com 正直なところ、この機能を知ったときは「え、こんな便利な機能あったの？」って感じでした。公式ドキュメントをちゃんと読んでない自分を殴りたくなりました。というか書くって言って書いてはいてかなり前なのにいろいろやることがあって公開は遅れました

はじめに AIコーディングエージェント（Claude Code、Cursor、Cline等）の普及により、開発効率は飛躍的に向上しました。しかし、複数のAIエージェントを同時に使用する際、以下のような課題に直面することがあります： ファイルの競合: 複数のエージェントが同じファイルを同時に編集 環境の汚染: 一つのエージェントの変更が他の作業に影響 作業追跡の困難: どのエージェントが何を変更したか把握しにくい これらの課題を解決するのが、Daggerが開発したContainer-Useです。 github.com Daggerとは何か DaggerはDockerの創設者Solomon Hykes氏が2018年に立ち上げた会社で、「DevOpsオペレーティングシステム」の構築を目指しています 。コンテナで開発者の問題を解決したHykesは、今度は「CI/CDの混乱状態」という開発者とインフ

2025年6月18日、KAGのLT会 #6で「Claude Codeどこまでも」というタイトルで登壇させていただきました。今回は、Claude Codeを実際に使い込んでみて感じた、エンジニアリングの本質的な変化について、登壇では時間の関係で話せなかった内容も含めて深掘りしていきたいと思います。 kddi-agile.connpass.com この記事では、Claude Codeの3週間の使用体験から得た気づき、開発手法の根本的な変化とその対応策、そして実践的な導入方法と具体的なテクニックについてお話しします。客観的な話はまた、これから出てくると思うのでとりあえず主観的に作りました。 客観性の落とし穴 (ちくまプリマー新書) 作者:村上靖彦筑摩書房Amazon 登壇資料 Claude Codeについて技術的な議論やデバッグしている結果の話をしようと思ったのですが、気がつくとこんなポエムにな

完全なる妄想。或いは自分の話。 第一章　改善ループ 僕がCoding Agentシステムに初めて触れたのは、2025年の春だった。生成AIにはすでに慣れ親しんでいた。流行に乗り遅れてはいけないと必死に勉強し、エディターの補完機能やコード生成ツールとして日常的に活用していた。ただ、当時の僕にとってそれはまだ「CLIで動く便利なコーディング支援ツール」程度の認識でしかなかった。「AIが90%のコードを自動生成」という謳い文句を見ても、半信半疑でターミナルを開いたのを覚えている。 $ coding-agent --init Coding Agent v1.0.0 初期化中... プロジェクト構造を分析しています... 最適化可能な箇所を特定しています... 改善提案を生成しています... 最初の一週間は、思ったよりも不具合があったり、指示通りにしてくれなかったり、前に言ったことを忘れたりしていた

はじめに 最近、ふと気づいたことがある。技術負債って、もう昔とは全然違うゲームになってるんじゃないか？いや、もっと正確に言うなら、ゲーム自体が終わろうとしているんじゃないか？ コーヒーを飲みながら、10年前に書いた自分のコードを眺めていた。当時は「きれいに書いた」つもりだったけど、いくつかの要望がありよく考えずに変更を加えた結果、負債の塊だ。でも、それを直すのに必要な時間とコストの計算が、根本的に変わってしまった。 いや、変わったどころか、もはや「時間とコスト」という概念すら意味をなさなくなりつつある。 syu-m-5151.hatenablog.com 私たちは技術負債を「悪いコード」として理解してきた。しかし、それは大きな誤解だった。Ward Cunninghamが1992年に生み出した原初の概念は、現在広く信じられている「技術的問題」とは根本的に異なっていた。 彼の言う負債とは、ソフ

[社内共有版「Claude Code、どこまでも」] はじめに Claude Codeを使い始めて1週間。私の開発スタイルは完全に変わった。 きっかけは3ヶ月前に書いた「生成AIといっしょ: 動作するきれいなコードを生成AIとつくる」という記事だった。当時はAIとの協業について考察していたが、正直なところ、まだ私が「運転席」に座っているつもりでいた。AIはあくまで「副操縦士」だと。 syu-m-5151.hatenablog.com 現実は違った。 実際にClaude Codeを使ってみて最初に感じたのは、自分の開発スタイルとAIの特性のミスマッチだった。私は根っからの「とりあえずコード書いてみよう」タイプ。設計書？計画？そんなものは書きながら考えればいい—それが私の流儀だった。 ところが、AIは違う。指示に対して忠実すぎるのだ。「認証機能を実装して」と曖昧に伝えれば、私の意図とは全く違う

はじめに Claude Code 使ってますか？ターミナルから Claude に直接コーディングタスクを投げられる便利なツールなんですが、デフォルト設定のまま使うのはちょっともったいない。というかいちいちいろんなことを聞いてきてめちゃくちゃダルい。 syu-m-5151.hatenablog.com settings.json をちゃんと設定すると、セキュリティも保ちつつ、もっと快適に使えるようになります。全体的に疲れている時の~/.claude/settings.json と~/.claude/CLAUDE.md · GitHub 私のデフォルトの設定も公開してますのでよかったら参考にしてください。 ここで読むのをやめる人のために言っておくと Claude Codeの設定は優先順位があるので覚えておくと良い です。あと、比較的に今は黎明期なので非推奨や追加機能が多いのでその点も注意が必要

はじめに 前回、「NeovimをCursorのように進化させる - yetone/avante.nvim の導入」を書いた。あの記事では、まるで自分だけの剣を鍛え上げていくように、エディターと共に成長していくPDEの哲学について語った。 syu-m-5151.hatenablog.com あれから数ヶ月、私のNeovimはavante.nvimによってCursor + Roo-Codeライクな体験を手に入れ、PDEとしてさらなる進化を遂げた。 しかし、告白しなければならないことがある。vimmerを自称しながら、実は日常的にCursorを使っていた。この矛盾と向き合う時が来た。 www.cursor.com そして先週の土曜日、私はClaude Codeを使い始めた。今日で1週間。短い期間だが、これが私のPDEに新たな可能性をもたらすことを確信している。そして、Cursor のサブスクを解

はじめに 生成AIを使ったコード開発が急速に普及している。GitHub Copilot、ChatGPT、Claude、そして各種IDEに統合されたAIアシスタントや独立したコーディングエージェント。これらのツールは開発効率を飛躍的に向上させ、もはやAIなしでの開発は考えられないという声も聞こえてくる（主に心の底から）。 しかし、この革新的な変化の中で、看過できない問題が顕在化している。現在のAIで生成したコードは、2年後の進化したAIで再生成すれば、より効率的で保守性の高いコードに置き換えられる。これ自体は技術進歩として歓迎すべきことだが、重要な情報が失われている。 それは「なぜそのコードをそのように実装したのか」という意思決定の記録だ。 この問題は単なる技術的な課題ではない。私たちがどのようにソフトウェアを作り、保守し、進化させていくかという、エンジニアリングの本質に関わる問題だ（そして

この記事で得られる3つのポイント 「つぶしが効く」エンジニアになる: 表面的な技術習得ではなく、根本原理の深い理解と問題解決能力が長期的な市場価値を創出する AI時代の新たな役割: テクノロジーと人間の強みを組み合わせ、AIとの効果的な協働を設計・実現できる「アーキテクト」としての視点 計画的偶発性の活用: 不確実性を受け入れ、専門性と横断性のバランス、継続的学習、そして「偶然を必然に変える」姿勢の重要性 はじめに みなさん、こんにちは！本日はアカリクの就職ラウンジイベント＠会津大学に来ていただき、ありがとうございます。「AI時代に市場価値を高めるキャリア戦略」というテーマでお話しさせていただきます。口頭で補足しながらいろいろやっていきます。よろしくお願いします。 acaric.jp 現役エンジニアとして日々AIの進化と自身のキャリアパスに向き合う中で、私が得た気づきや思考を皆さんと共有で

はじめに ある日のこと、私はブログを書いていました。ブログをレビューしたり、修正したり。そんな日々の中で、ふと思ったのです。「あれ？自分が書いたブログ記事、本当に役に立っているのかな？」と。 皆さんも一度は感じたことがあるのではないでしょうか。せっかく時間をかけて書いた記事が、実は的外れだったかもしれない、という不安。「もっとこうすればよかった」という後悔。あるいは「この記事、本当に価値があるのか」という疑問。 そんな思いを抱えながら、私はあることに気づきました。ブログ記事を評価する明確な基準がないということに。プログラミングにはコードレビューがあり、デザインにはクリティークがあります。でも、技術ブログには？ そこで考えました。もしブログ記事を客観的に評価できるプロンプトがあれば、多少なり自分の記事をより良くするヒントになるのではないか、と。単なる「良い/悪い」ではなく、複数の観点から数値

soudai.hatenablog.com そーだいさんの「頑張らなくてもいいから、成果で応えよう」という記事を読み、「頑張ること」について改めて考えさせられた。 「頑張る」の幻想と私たちの関係 日本文化においてというか自分が育ってきた環境では「頑張る」という言葉には特別な地位があった。子どもの頃から「頑張れ」と叱咤激励され、「頑張ります」と答えることが社会的な美徳や道徳的な行いとされてきた。多くの場面で「頑張ります」と宣言するだけで、一時的に評価されるか、少なくとも批判を免れる魔法のような効果を持っている。 しかし、この「頑張る」という概念を現場で聞くと自分も奇妙だと感じる。専門的な仕事に対する報酬は、結局のところ労力の投入量ではなく、生み出された価値に対して支払われるものだ。高額な費用を支払う依頼者が期待するのは、徹夜して疲れた顔をすることではなく、問題解決の価値を提供することだろう。

はじめに ああ、ついに来てしまった。30歳という、人生の大きな節目。私は今、20代最後の週を迎えている。誰だ？清々しい気持ちとか言ってたやつは⋯。 正直に告白しよう。これから綴る文章は、決して効率的な読み物ではない。むしろ、投資対効果という観点では、あまり賢明とは言えない時間の使い方かもしれない。同じ時間で技術書を読むなり、コードを書くなり、より直接的な成長に繋がる活動はたくさんある。それでも、もしかしたらこの言葉が、誰かの心に小さな波紋を投げかけるかもしれない。そんな期待を胸に、筆を進めていきたい。 思えば20代のはじめの私は、まるで迷宮に迷い込んだ勇者の気持ちだった。10代の頃は、親や先生が道標となり、友人たちと同じペースで歩んでいけば良かった。進学、部活、受験―目標は明確で、努力の方向性も定まっていた。しかし20代に入ると、そんな心地よい"レール"は突如として途切れる。誰も正解を教え

はじめに ある日のこと、私はもしくはあなたは思いつきました。そう、自分の考えを発信してみようと。それはまるで、小さな紙飛行機を窓から放り投げるような、どこまで飛ぶかわからない冒険でした。そんなわけで画面に向かい、キーボードを叩き始めたのですが、すぐに奇妙な不安が襲ってきたのです。 ほら、誰かがそっと後ろから覗き込んで「それ、間違ってるよ」とか「それって昔の話でしょ」なんて言ってくるかもしれない。もっと恐ろしいのは「もっといいやり方があるのに」という呪文めいた言葉です。そんな呪文を浴びせられたら、私はきっと透明人間になりたくなるに違いありません。 でも不思議なもので、そういう批判の声が聞こえてくるのは、実は自分の頭の中だったりするんですよね。まだ何も書いていないのに、もうすでに架空の批判者と対話している。ある意味、私たちは常に誰かと対話している生き物なのかもしれません。 そこで考えたのです。

はじめに あなたは最後に技術的な記事を読んだとき、何を求めていただろうか？ あなたは最後に技術的な発表を聞いたとき、何を求めていただろうか？ この二つの問いに対する答えは、おそらく大きく異なるのではないだろうか。 記事を読むとき、私は再現可能な手順、明確なコード例、具体的な問題解決の道筋を期待する。一方、技術発表を聞くとき、新たな視点やアイデア、そして時に「なるほど、そういう考え方があるのか」という気づきを求めている。 技術を共有する手段として、ブログを書き、カンファレンスで登壇する。一見すると同じ「知識共有」という行為に見えるが、この二つは根本的に異なる体験を生み出している。ブログは時間に縛られず、読者が自分のペースで情報を咀嚼できる。一方、登壇は限られた時間の中で、話者の熱量や会場の空気感とともに知識が伝わる。 この違いは偶然ではなく、それぞれのメディアには、最適な伝え方があると私は考

はじめに 生成AIの急速な発展により、様々なAIアシスタントが日常的にシェルコマンドを提案してくれるようになりました。また、最新のAI統合ツールは、ユーザーの自然言語指示からコマンドを生成し、場合によっては自動的に実行することさえあります。このような環境では、AIが提案または実行するシェルコマンドを正確に理解し、安全に活用するための知識が不可欠となっています。 「コマンドプロンプトやLinuxなんて難しそう」「プログラミングは専門家の領域」と思っている方こそ、この記事をお読みください。AIツールを使う現代では、専門知識がなくても基本を知っておくことで安全性が大きく変わります。 本記事では、生成AIが提案するシェルコマンドを適切に評価し、安全に活用するために必要なシェルの基本知識と「シェル芸」と呼ばれる技術について詳しく解説します。難しい専門用語は極力避け、初心者の方でも理解できるよう丁寧に

はじめに あなたは日々、何かを見ている。そう、コードを。エラーを。ドキュメントを。解決策を。 そして、それは誰も見ていないものかもしれない。あるいは、多くの人が同じものを見ているのに、誰も記録に残していないのかもしれない。 「自分なんてまだ1年目、2年目。経験が浅いから書くことなんてない」 そんな思いを抱いていませんか？ しかし、その思い込みは真実ではありません。むしろ、経験の浅さこそが、あなたにしか書けない貴重な視点を生み出します。初めて学ぶ時の困惑、理解するまでの試行錯誤、そして「あ、わかった！」という喜び—これらの生々しい体験は、あなたがまさに今感じているからこそ書ける宝物なのです。 「専門家でもないのにブログなんて書けない」「自分の書いたものなんて誰も読まないだろう」という思いも、単なる幻想です。誰もが最初から専門家ではなかった。今あなたが参考にしている記事を書いた人も、最初は不安

はじめに 最近注目を集めているModel Context Protocol（MCP）は、大規模言語モデル（LLM）に外部ツールやサービスへのアクセス能力を提供するための標準プロトコルです。中でも公式が提供しているRust SDKはあまり注目されていませんが、私自身が必要としているためこのドキュメントを作成します。 github.com 以前は自前で実装していましたが、公式SDKが公開されたことでそちらを検討するのが良いと考えました。私の実装と比較してかなり洗練されている点が多く、多くの学びを得ることができました。 syu-m-5151.hatenablog.com この記事では、MCP Rust SDKの内部実装を深掘りし、どのようにRustの強力な型システムと非同期プログラミングモデルが活用されているかを解説します。コードの詳細な分析を通して、Rustの優れた設計パターンや実装テクニック

※こちらは社内で発表したものを外部で登壇できるように修正したものです。 はじめに 2021年にGitHub Copilotが発表され、2022年に一般利用可能になって以来、生成AIはソフトウェア開発の世界に急速に浸透してきました。「動作するきれいなコード」はソフトウェア開発の理想とされてきましたが、生成AIの登場によってこの理想に到達する道筋が大きく変化しています。本記事では、テスト駆動開発の原典である『テスト駆動開発』の基本理念を踏まえ、生成AIとの協業によって「動作するきれいなコード」を実現する方法について考察します。 「動作するきれいなコード」とは何か t-wada氏がSeleniumConf Tokyo 2019での基調講演で引用したように、テスト駆動開発のゴールは「動作するきれいなコード（Clean code that works）」です。Kent Beckによるテスト駆動開発の

はじめに こんにちは！今回は、私が最近開発した tfmcp というツールを紹介します。これは Terraform を LLM（大規模言語モデル）から操作できるようにするツールで、Model Context Protocol (MCP) を活用しています。 github.com このブログが良ければ読者になったり、GitHub リポジトリにStarをいただけると開発の励みになります。nwiizoをフォロワーしてくれるのもありがたいです。より良いツール開発のためのフィードバックもお待ちしています！ MCP とは何か？ 記事を始める前に、まず MCP (Model Context Protocol) について簡単に説明しましょう。MCP についてより詳しい情報は、公式ドキュメント modelcontextprotocol.io や Anthropic の Model Context Protoc

はじめに 「Taming Your Dragon: Addressing Your Technical Debt」を読み終えて、技術的負債という厄介な問題への理解が大きく深まりました。この本は2024年7月にO'Reillyから出版され、技術的負債というドラゴンの正体とその退治法について包括的に解説しています。多くのエンジニアにとって身近な「誰がこんなコードを書いたんだ！...あ、私か」という経験から始まり、技術的負債の本質と効果的な管理方法へと読者を導いてくれます。 learning.oreilly.com 私たちエンジニアは普段、「美しいコードを書く芸術家」か「とりあえず動けばOKの実務家」かという二択で自分を見がちです。しかし実際には、納期に追われて「まぁ動くからいっか」と書いたコードが、数ヶ月後に「誰だこんな恐ろしいものを作ったのは！」という悲鳴に変わる悪夢のループから抜け出せない

anond.hatelabo.jp この記事を読み、その内容は学生だけでなく、ソフトウェアエンジニアの教育にも適用できると考えました。以下、ソフトウェアエンジニア（以降、技術者と表記）の教育について、私見を述べさせていただきます。 はじめに 新人エンジニアや学生のOJTやハンズオン研修を担当する中で日々実感することがあります。生成AIの台頭により従来の指導方法が大きく揺らいでいるという現実です。特に、表面的な成果物の質と実際の理解度の乖離が、技術者教育における新たな課題として浮き彫りになってきています。 この変化は、技術教育に関わる私たち全員に、新たな挑戦と機会をもたらしています。生成AIは確かに技術教育の在り方を根本から問い直すきっかけとなりましたが、それは同時に、より本質的な技術力の育成について考え直す機会でもあります。技術の進化に伴う変化は不可避ですが、その中で私たちにできることは、

はじめに バズっている技術ブログやSNSの投稿を見ていて「今さらこんな基本的なTipsが数千いいねされるのか」と感じることはありませんか。「とりあえずDockerを使ってみよう」「React超入門」といった手取り足取り系の投稿がバズり続け、タイムラインには毎日のように初心者向けコンテンツが流れています。同じような入門記事が異なる執筆者によって際限なく生み出されるこの状況は、技術情報の共有における興味深い現象と言えるでしょう。では、なぜこのような現象が続いているのでしょうか。 「学習」に対する一般的な認識 多くの普通の人にとって「学習」は快適な体験であるべきだという認識があります。自分が理解できる範囲の内容を読み、既存の知識と結びつけて徐々に理解を深めていく。分からないことがあれば基礎的な内容に立ち返る。実際、人間の脳は安全な環境で学習することを好む傾向にあり、多くの人は「コンフォートゾーン

はじめに Protocol BuffersとRustの実践的な学習を目的として図書管理システムを開発しました。 システムの構築にあたってはBufによるスキーマ管理とコード生成を採用することで開発環境を実現しています。今回の実装を通じてRustにおけるgRPCサービスの構築手法について理解を深めることができました。 buf.build フロントエンド開発については今後の課題として検討しています。 Remixが気になっているので実装したいと思ってます。本記事ではバックエンド実装に焦点を当てて解説します。 特にRustのエコシステムにおけるtonicやSQLxといったライブラリの活用方法に着目します。これらの実装を通じて得られた知見は他のRustプロジェクトにも応用可能な内容となっています。 学習目的で実装したコードなので何かに活用していただければ幸いです。 github.com プロジェクトの

「もはやCopilotなしでは開発できない」 「Cursorが体験として革新的すぎる」 「Clineこそ俺達が求めていたものだ！」 「とにかく新世代のAIエディターが最高！」 はじめに 開発者のタイムラインを開けば、そんな投稿で溢れかえっています。確かに、AIによる開発支援は革新的で、プログラミングの未来を感じさせるものです。特に最近では、単なるコード補完を超えて、より多機能なAIアシスタントとしての役割を担うツールが増えてきています。 実は、愛用のNeovimでもこうした最新のAI機能を導入できるんです。しかも、使い慣れたキーバインドやプラグインはそのまま。今回はavante.nvimというプラグインを使って、NeovimをAIパワード開発環境へと進化させる方法をご紹介します。 github.com このプラグインは、私たちvimmerにとって既に身近な存在であるcopilot.luaの