——「何を作るべきか」を選び、腹を括ることの価値 この記事の核心：AIがコードを書く時代になっても、「何を作るべきか」を選び、腹を括り、うまくいかなければ別の手を打つのは人間の仕事だ。なぜなら、痛みのない決断は決断ではなく計算だから。本稿では、要件定義を「合意形成」として捉え直し、2025年のAIエージェント元年に人間が担うべき役割を考える。 はじめに AIがコードを書く時代になりました。「ファイル監視ツールを作って」と指示すると、動くコードが出てきます。それだけではありません。2025年現在、AIエージェントはファイルを読み、テストを実行し、エラーを修正し、プルリクエストまで作成できます。 便利になった分、私たちの仕事は減るのでしょうか。「作る」作業は確かに減ります。しかし「何を作らせるか」「どこで人間が介入するか」を決める仕事は増えます。AIが「作る」を担うからこそ、「選ぶ」の重みが増

なぜRSSリーダーか 情報収集は基本活字で、昔からRSSリーダーをよく使ってきた。Google Readerの時代からFeedly、Miniflux、FreshRSSと渡り歩いたしPocketのようなRead it later系も使ってきたが落ち着いて使い続けられるサービスがなかった (もっとここがこうだったらな〜とか。サービス自体がなくなることもあった) そもそも自分がRSSリーダーを使うのは、情報源を自分でコントロールしたいというのが大きい。SNSのアルゴリズムはエンゲージメントに最適化されているため、気づかないうちにフィルターバブルに閉じ込められる。流れてくる情報は「自分が見たいもの」であって「自分が知るべきもの」とは限らない[1]。RSSリーダーはその対極にある。購読するフィードを自分で選び、アルゴリズムの介在なしに情報が届く。プロアクティブに情報源を設計することで、視野を意図的に

仕様駆動開発なんて要らない、やめておけ。 仕様駆動開発不要論が界隈を飛び交っています。 しもしさんの「仕様駆動開発はやめた方がええ」という記事を読んで、共感しました。めちゃくちゃわかる。でも、うーん、ちょっと待てよ、と。 人の意見を鵜呑みにせずに、いったん自分の中で本当に不要なのか考えてみたいと思いました。 仕様駆動開発不要論について しもしさんの主張を整理すると、 実装に関するドキュメントは不要で、仕様はすべてコードにある。 ドキュメントとコードの両方をメンテナンスするコストが大きすぎる。 AIエージェント時代にはドキュメントの更新が確率的で、トークンの無駄も大きい。 コードは最新なのにドキュメントは半年前の設計のままってことありません？ 新しく入ったメンバーがドキュメントを信じてコードを読むと、現実のコードとの乖離に混乱する。これって、ドキュメントがないよりタチが悪いんですよねぇ。 さ

TL;DR CLAUDE.mdはSystem Promptではなく、User Messageとして注入される セッション後半になると影響力が薄れるため、セッションを通して守らせたいルールの置き場所には向かない CLAUDE.mdにはセッション開始時の作業を助ける情報だけを書き、ルールは .claude/rules/ に置く はじめに Claude Codeを使っている人なら、CLAUDE.mdに何を書くかで一度は悩んだことがあるのではないでしょうか。 コーディングルール、命名規則、テストの方針、コミットメッセージのフォーマット。色々なことを書いている人が多いと思います。自分もそうでした。 ただ、CLAUDE.mdの内部的な扱われ方を知ると、そこに書くべきものの考え方が結構変わります。結論から言うと、CLAUDE.mdにはセッション開始時の作業を助ける情報だけを書いて、ルールは .claud

本日社内発令とのことで、退職エントリを書きます。 3/2発令、4/15退職です。退職理由は出社頻度の増加が急すぎて家庭側の負荷を吸収しきれないと判断したのが7割で、残りはノリです。 以下は「僕、大分頑張ったな〜」っていう振り返りなので、そういうノリが苦手な人は読まない方がいいかもしれません。 2019年に当時ヤフーと合併前だったLINEに入社して、社内のプライベートクラウド基盤の開発、運用をやってきました。 (LINEに入るまでの経緯は以下参照) 3年間ちょっと勤めたNTTテクノクロスを退職しました - blog.manj.ioNTTやめたよ blog.manj.io 入社した直後に部署内にSREチームが立ち上がり、当時急拡大していた社内クラウド(以後Verda)でパンクしかけていたデプロイシステムや監視システムを頑張って書き直していたらそのまま3年くらい経過してました。 大量の物理サーバ

2026年2月26日「開発生産性のその先へ、AI生産性について語りたい」発表資料 https://forkwell.connpass.com/event/384640/

確定申告、めんどくさくないですか？ 年に1回しかやらないから毎年やり方を忘れる。レシートの山を前にしてうんざりする。帳簿をつけて、決算書を作って、税額を計算して、申告書を提出する――気が遠くなるほど長い道のりです。個人事業主やフリーランスの方なら、この苦しみに共感してもらえると思います。 「もう全部 AI にやらせたい」。そう思って作ったのが、確定申告を自動化する Agent Skill「shinkoku」です。この記事では、作った動機、できること、セットアップ方法、テストによる品質保証について紹介します。 作った動機 私は毎年、確定申告の時期になると憂鬱な気持ちになっていました。 年に1回しかやらないから、去年の記憶なんて綺麗さっぱり消えているんですよね。「去年どうやったっけ？」が毎年の恒例行事で、結局ゼロから調べ直す羽目になります。 そして1年分のレシートと領収書の山。1枚ずつ確認して

お金、それも給料の話は、あさましい、ということになっている。婚活パーティーでもなければ隣の席の人間がいくら貰っているか堂々と聞くこともできない。 かつてGoogleで、自分の給料を全社員が見られる共有スプレッドシートに書き込み、公開を促した女性が現れてとんでもない騒ぎになったことがある。その行為の是非はともかく、不透明さによって守られていた上層部の平和は破られ、結果として彼女が社内で干される原因にもなったようだ。 このように給料の周りには、常に不透明な霧があって、その秘密は厳然と守られている。一方で、物価が上昇し、新卒の初任給が30万に達し、ボーナス平均が100万を超えたなどというニュースが連日報道されていて、先月のアフィリエイト収入が240円で、4月から素寒貧の無職になることが決定しているこのブログの主としては、気が気でない。 今こそ、私たちは給料の話をしなくてはならないのかもしれない。

この記事はSansan Advent Calendar 2025 - Adventarの2日目の記事です🎄 はじめに 背景 APIドキュメントに求めるもの ProtobufスキーマをOpenAPIスキーマに変換するというアプローチ protoc-gen-connect-openapi の紹介 protoc-gen-connect-openapiを利用する上で工夫したこと protoc-gen-connect-openapi の設定 Protobufスキーマの定義にOpenAPI特有の情報を埋め込む protoファイルに書きづらい情報は独立したyamlに定義する まとめ はじめに こんにちは！技術本部Platform Engineering Unitの樋口です。 これまでBill One EUの一員として認証基盤を開発していましたが、2025年6月に新設されたPlatform EUへチーム

はじめに 金曜日の夜、ベッドの上でこの文章を書き始めている。 先週の土日は何をしていたかと聞かれたら、たぶん「寝てた」と答える。嘘ではない。ベッドにいた時間は長かった。ただ、眠っていたかというと怪しい。スマホを持ったまま横になって、気づいたら夕方だった。そういう二日間だった。 休んだのか、と聞かれると困る。 体は動かしていない。仕事もしていない。だから休んだと言えば休んだのだろう。でも、回復したかというと、していない。月曜の朝を迎える自分は、金曜の夜の自分より確実に疲れている。 何もしていないのに。何もしていないから、かもしれない。 30歳になった。エンジニアとして働いている。在宅勤務というやつだ。2025年、AIエージェントが当たり前になった時代を生きている。 AIは文句を言わない。疲れたとも言わない。24時間動ける。私にはそれができない。コーヒーがないと朝は動けないし、金曜の午後は集中

Intro 「Background Fetch を使っているのが、世界であなたのサイトだけなんだけど、この機能消しても良い?」 と、TPAC 2025 の会場で、Chrome の Service Worker チームの開発者と話していた際に言われた。 Background Fetch Background Fetch は、Service Worker を使って、文字通り Fetch をバックグラウンドで行う機能だ。 特に Android では、ダウンロードの UI にプログレスが表示され、終わったら Cache API に保存される。 筆者が運営している mozaic.fm のサイトは、Podcast アプリと同じようなことを Web でもできるように PWA 化し、様々な機能を試していた。 PWA: モバイルでインストールしてアプリとして使える Background Fetch: エピソ

久々にnoteを書いています。いつもは個人ブログにソフトウェアエンジニアリングについて書いていますが、今回はエンジニアリングに全く関係がないことなのでnoteを使おうと思います。 タイトルの通り、中古マンションを買いました。 新卒のころからいつかは欲しいなぁと思っていましたが、直近のライフスタイルの変化や社会情勢の変化を考えると、「今のうちに買っておいたほうが良いだろう」ということで購入を決断しました。契約は数ヶ月以上前に完了し、現在は新しい家に住んでいます。 マンション購入は、相談する相手がいない中での戦いでした。自分はまだ20代で、まわりで家を買う人はまだほとんどいません。自力で情報収集したのですが、結構苦労したのでせっかくの機会だし調べたことをまとめようと思います。気づけば1万字を超える長文になってしまったので、お時間のある際にでもご覧ください。 なお、これ以降は東京23区に住むこと

プロローグ 2025/05/22 Claude 4 リリース後、多くの人間が一段階未来へきたと感じていることだろう。 今まで超えられないと感じていた壁を超えたような感覚がある。 dd 更に Claude 4 を、LLMを使いこなしたい。そう思い Claude 4 プロンプトエンジニアリングのベストプラクティスに目を通した。 私の脳に強烈なインパクトを残したのが以下のセクションだった... 面白すぎる...! 本題 どうやら奨励するとAIは頑張れるらしい。 ビジュアル表現が豊かになるらしい。 英語原文だと以下のような内容だ。 For frontend code generation, you can steer Claude 4 models to create complex, detailed, and interactive designs by providing explicit

Mozillaが、自社が提供するウェブページ保存サービス「Pocket」を2025年7月8日に終了し、同年10月9日にすべてのアカウントとデータを削除すると発表しました。「Pocketのようにウェブページの全文を保存でき、かつ検索可能なサービス」という縛りで代替となるサービスを探してみました。 Pocket終了の発表内容については、以下の記事に詳しくまとめています。 Mozillaが後で読むサービスの「Pocket」とAIでサクラレビューを検出する「Fakespot」の終了を発表、データが消えるのでエクスポートの必要あり - GIGAZINE Pocketのリンクデータをエクスポートする方法は、以下のページにまとめられています。手順は簡単で、Pocketの「アカウント」にある「オプション」から「エクスポート」を選択し、「HTMLファイルをエクスポート」のボタンをクリックすれば、生成されたH

一時期Ruby on RailsのERB + jQueryベースのフロントエンドをReactやVueのモダンフロントエンドにリプレイスするのが流行りました。私も現場でこういう例を複数見ています。 しかしどれも途中で止まっています。半分にも届かないぐらいのところで "ERB + jQuery"だったものが "ERB + jQuery + React + Next.js"とか"ERB + jQuery + Vue"になっています。 複雑度はむしろ明確に増しています そこで、こういう結末が一般的なのかどうか、ウェブを検索して調べてみました。 タイミー社の例 Rails (多分ERB) + jQueryが出発点 30画面 Next.jsのSPAに移行 3年間かかった （2年弱の時点で一回中断） クックパッド社の例 2020年にRails (多分ERB) + CoffeeScript/jQueryを

The Model Context Protocol (MCP) is gaining traction as a mechanism to connect Large Language Models (LLMs), like GPT, Gemini, or Claude, to external tools and APIs in a standardized, secure, and reusable way. What is MCP?Think of MCP as a universal translation layer that offers APIs to LLMs in the form of tools/functions. Although LLMs excel at language, they don't natively understand the specifi

LayerX バクラク事業部 Enabling チームでスタッフエンジニアをしている izumin5210 です。 Ubie さんの「社内デザインシステムをMCPサーバー化したらUI実装が爆速になった」を拝見し、悔しかった感動したので、自分でも試してみました。 MCP ツール設計 以下に引用する Ubie さんのスライドで解説されているとおりですが、現行モデルでは全コンポーネントのコードやルールを一気に渡してもノイズが多くなりすぎるためか、満足のいく性能は出ませんでした。 これは MCP サーバ化したとしても同様で、Tool 1回の呼び出しで全コンポーネントの詳細情報をすべて返すとやはり情報がぼやけてしまいます。 AI Coding Agent Enablement - エージェントを自走させよう (p.23) これらを踏まえると、以下のような2つのツールに分けて提供するのがよさそうだと判

バクラク事業部エンジニアの id:upamune です。最近、ローカル開発環境構築に対して人より熱意があるということに気がつきました。 ということで、この記事ではバクラク事業部での、ローカル開発環境構築の今について書きます。 はじめに 近頃、AIの発展により開発、特にコーディングのハードルは大きく下がりました。弊社でもプロダクトマネージャーやデザイナーがエンジニアに混じってPRを出しています。 詳しくはバクラクビジネスカードでプロダクトマネージャーをしている原山がnoteを書いているのでご覧ください。 note.com しかし、ここで開発の障壁となるのが最初のローカル開発環境の構築です。セットアップドキュメントは存在しますが、主にソフトウェアエンジニア向けに書かれており、ローカルでアプリケーションを動かすだけなら不要なツールまでまとめてインストールするため、時間のかかるものになっていました

draw.ioでレイヤーを使ったらAWS構成図が捗ったお話AWSを使っている方なら、dwar.ioを使って構成図を書く機会が結構あると思います。構成図を書く時のイラッとをなくすレイヤーという機能を知ったのでご紹介したいと思います。え？今更知ったの？そんなの知ってるよ。と言われちゃうかもですが、ご紹介させてくださいませ。 その前に、構成図書く時にどう書いたら良いんだろう、、、となる時ありますよね。参考にしている良い記事あるのでご紹介させてください。今まで結構雰囲気で書いていたのですが、この記事を見てから綺麗にかけるようになりました。 AWSのアーキテクチャ図を描くときに意識していること それではレイヤーのお話に行きたいと思います。ECSコンテナを編集したい場合、まずレイヤーを使っていないときは、こうなりますよね。 邪魔なのをどかしてどかして、やっと編集できます。次回すぐ編集できるように最前面