はてなブックマーク

最近AIを使って仕事をしていると、特定分野の仕事をする時、その分野の基礎知識があればAIをうまく活用できるが、そうでないと全く活用できないということが多々ある。そのためいろんな分野の基礎知識を付けられると良さそうだと思い、経営系のことを学ぶため「世界標準の経営理論」を読んだ。 世界標準の経営理論 作者:入山 章栄ダイヤモンド社Amazon 経営理論の基礎を知る部分としても非常に面白かったのだけど、最初に読み始めた意図とは異なり、Engineering Managerの仕事で参考にできることが多かった。たとえば面白かったなと思ったのは 理論には必ず適用範囲がある。適用範囲が大手企業の限定の場合に、スタートアップには役立たない可能性がある。そのため適用範囲を理解することが大切 気づき：エンジニアリングをしていると、いろいろな手法・フレームワーク・ツールが出てくる。この時に「適用範囲」を理解して

表題のとおり、Claude Codeが4~5並列にSubAgentを起動した時に自宅ネットワークが死ぬ問題が起きていた。その状況になると次のような現象が起きていた。 pingなども含めて一切外部との通信ができなくなる Claude Codeを一旦止めて数分待つと復活する この現象について知人に相談しながら対応を進めたところ解消できたので、ログとしてブログに残しておく。ただしネットワークについて専門分野ではないため、かなり間違ったことを書くかもしれない。その場合は指摘してもらえると嬉しい。 自宅ネットワークの構成 ISP: enひかり + v6プラスオプション ルーター: Aterm 2600HP4 再現させる まず再現はかなり簡単に取れた。Claudeを起動し、「どういう内容でもいいので、10並列で何かの調査を行なってみて」と指示を出すと、Explore SubAgentが一斉に起動する。

京都アジャイル勉強会LT大会 #118 - connpassに参加してきました。LT発表の内容の密度が高く非常に楽しめました。特にコンフリクトの話が面白かったので、ぜひ資料を公開してほしいと思いました。また懇親会でも深掘りした話が出来て良かったです。また忘年会があるらしいので行ってみようと思います。 僕はせっかくの勉強会ということで「EMこそClaude Codeでコード調査しよう」という発表をしました。資料はこちら。 speakerdeck.com 以下書き起こしです。 EMこそClaude Codeでコード調査しよう 開発チームを持つEMは、他チーム・他職種から質問を受けることが多い 回答する時どうする？ 詳しそうなエンジニアに聞く 自分でコードを読んでみる Claude Codeやcodexを活用して調査する 質問が来たら、EMこそClaude Codeでコード調査することをおすすめ

RAGでのデータ整形(改行・インデント)がLLMの回答精度に与える影響を検証したでは、ダミーのテストデータやテストケースを色々作っている。実はこのデータはAIと壁打ちしながら作ったので、やり方を共有する。 ダミーのテストデータを作る まずslack-explorer-mcpのメッセージ検索のレスポンスを模したダミーデータを用意したかった。流れとしては、slack-explorer-mcpで適当にメッセージ検索してJSONをゲット => そのJSONをClaude Codeに与えてダミーデータに変えてもらう、ということをした。 下記の会話内容が壁打ち&データ生成の流れ。最初からはうまくいかないので、データを作りながら修正していった。 > Slack Explorer MCPの挙動を色々試すため、ダミーのMessageのJSONを用意したい。以下のJSONをフォーマット例として、スレッド内メッ

slack-explorer-mcpでは、該当メッセージのpermalink URLをレスポンスで返さずに、利用側のAI Agentで組み立ててもらっている。なぜなら、permalinkをメッセージごとに返してしまうとトークン消費量が非常に多くなってしまうからだ。permalinkは他で返しているデータで再構築できるため省略し、利用側で組み立ててもらうことでトークン節約をしている。しかし、この方法だとうまくいったりうまくいかなかったりという現象が起きていた。 slack-explorer-mcpは現状はonelineのJSON形式で巨大なレスポンスを返している。これを人間にも読みやすい改行・インデントありのJSON形式にすることでLLMにとっても精度が上がるのかを知りたくなった。 そこで今回は、データの整形方法（改行・インデントの有無）がLLMの回答精度に与える影響を検証した。検証のテスト

最近Claude Codeのスラッシュコマンドなど、AIによるコード生成をさせる時、ドキュメントを参照するだけより、ドキュメントを参照した後に類似を自動検索させた方が生成の精度が上がると感じた。今回はその方法を紹介する。 ドキュメントだけで生成すると細かいニュアンスで気になることが多い コード生成をさせる時、何も無しでいきなり生成するよりも、コーディング規約やデータベース設計ガイドラインなど、チームで決めたルールを読み込ませてから生成する方が精度が上がると言われている。LLMの特性上、何もルールがないよりチームルールを明示することで、それに近いものが生成されるのは自明だ。 一方それだけだと「だいたい合ってるんだけど、細かいところで気になるなあ」と感じることが多かった。たとえば書き方がプロジェクト内の他の場所と少し違うなど。 ドキュメントを参照した後に類似を自動検索させる 「だいたい合ってる

AIコーディング関連で知見も溜まってきたので、「詳しくない分野でのVibe Codingで困ったことと学び」という発表をしてきました。発表資料を共有します。 speakerdeck.com オンラインで3年ぶり、オフラインで6年ぶりの発表だったっぽい...久々で緊張しましたが、良い発表の機会を作ってくれた運営の皆さまありがとうございました！ 以下、スライドを文字起こししたものです。 スライド文字起こし 今日話すこと Vibe Codingで、サーバーサイドエンジニアが経験のないiOSアプリを作った その中で困ったことと学びを紹介 初iOSアプリ開発のきっかけ その日やる気を出すためだけのシンプルなTODOアプリが欲しかった Vibe Codingによって、開発経験のないiOSアプリも簡単に高速に開発できるのでは？ 実際に作ってリリースした！ Daily Do AIをフル活用し、Vibe C

【2025/10/02補足追記】書き方が悪かったため対応関係が曖昧になっていたので追記。対応関係としては、変換層としてのLLM・コンパイラ・SaaS事業主で、SaaS事業主によるSaaS提供では内部の詳細仕様はブラックボックスのまま信頼するので確率的と捉えられるという話でした。以下対応関係のイメージ 自然言語 => LLM（もしくはAIエージェント） => コード 高級言語 => コンパイラ => アセンブリ 何らかの社会課題 => SaaS事業主 => SaaS 最近「高級言語 => コンパイラ => アセンブリのように、自然言語 => AI => コードもそのうちコードを見なくて済むようになる」のような話題を見かけることがある。しかしAIによるコード生成は、コンパイラじゃなく、むしろSaaSと比較するべきなのではないかと思った。 まずコンパイラとAIによるコード生成の決定的な違いは、決

この記事で紹介したSlack Explorer MCPをStreamable HTTPに対応した。どこかでホストしておけばChatGPTなどからRemote MCP経由で簡単に接続できるようになったので、その使い方を紹介する。 起動方法は以下の通り。 # Streamable HTTPモードで起動（デフォルトポート: 8080） docker run -i --rm --pull always \ -e TRANSPORT=http \ -p 8080:8080 \ ghcr.io/shibayu36/slack-explorer-mcp:latest # カスタムポートで起動 docker run -i --rm --pull always \ -e TRANSPORT=http \ -e HTTP_PORT=9090 \ -p 9090:9090 \ ghcr.io/shibayu36

自分がブログ記事を書いている理由の1つは、ブログを書くことで自分の理解が深まるからだ。そのため理解を深めたい内容だったら、AIにブログ記事を書かせるより、自分ですべて書いた方が良いと考えていた。 しかし最近、Claude Codeによる執筆環境を整えた結果、AIにブログを書かせた方が、むしろ自分の理解が深まっているのではと思い始めた。たとえば「経験を積むほどインプット出来ていない感覚になりやすいのではないか」という記事を書いたとき、このような感覚になった。 なぜこのように感じたのか、理由は大きく3つありそうだ。 AIがインタビュワーとして機能する。「それってどういうこと？」「具体例は？」といった問いかけによって、自分の中の暗黙知が引き出される 細かい文章表現に気を取られずに、「何を伝えたいか」「話題の繋がりは何か」という構造レベルの思考に集中できる AIがたまに自分の全く想像していなかった

あらたまさんの「なんとなく最近インプットできていない気がする」というポッドキャストを聞いて、自分も似た感覚を持っていることに気づいた。5年、10年とエンジニアを続けていると、こういう感覚になる人は多いんじゃないかと思う。このことについて自分の考えをXに書いたが、もう少し整理してブログにしてみる。 ある程度経験を積むと、一つの本から得られる新しい発見がどんどん減ってきて、結果としてインプットした気になれない、という感覚を僕は持ってしまってる 箸休め：インプット・アウトプット、もう疲れちゃって 全然動けなくてェ… #あらたまいくお https://t.co/ATNlcUr89n— 柴崎優季 (@shibayu36) 2025年9月16日 インプットが薄く感じる理由 そもそもインプットできた感覚ってなんだろうと考えてみると、新しい知識を多く学べた時に強く感じるものなのかなと思う。 エンジニアにな

Claude Codeを使って開発していると、生成されるcommit messageが冗長すぎるという問題に直面する。最近リリースされたサブエージェント機能を使うとこの問題を解決できたので、その方法を共有する。 Claude Codeのcommit messageの課題 Claude Codeのセッションで実装が終わったときに git commit を実行させると、以下のようなめちゃくちゃ冗長なcommit messageが生成される。 Add describe_tables e2e test and refactor MCP initialization - Add comprehensive e2e test for describe_tables tool - Refactor MCP server initialization into reusable functions - s

大吉祥寺.pm 2025に行ってきた。今回は前夜祭&懇親会、本編&懇親会&ナイトパーティと、すべてに参加して楽しみ切ってきた！ 発表として印象に残ったのは、yoku0825さん、sotarokさん、nrsさんの3人の発表だった。 まずyoku0825さんの「2025年になってもまだMySQLが好き」は、MariaDBとMySQLって単にforkされた似たものだと自分が思っていた無知を打ち砕かれる発表だった。logfileがMariaDBだと一本になってしまってあまりにも追記が早いとクラッシュするというのも面白すぎる。発表から「本当にMySQLが好きなんだな」という熱量を感じられてとても良かった。 sotarokさんの「大個人開発サービス時代にプラットフォームはどう生きるか」も印象に残った。Vibe Codingが出始めてから、自分もめちゃくちゃ個人開発が楽しいのでとても共感した。個人サービ

エンジニアリングをしていると、「なぜ現在こうなっているか」について調べたくなることがよくある。コードを読んでも、なぜその設計判断がされたのか、なぜその仕様になっているのかが分からないことが多い。 歴史的経緯はコミットログ、GitHub Pull Request、Slackでの議論などに残っていることが多い。これらの情報を組み合わせることで、コードには表れない設計判断の背景や仕様決定の経緯、トラブルシューティングの過程などを発見できる。 しかし、Slackから過去の議論を探すのは結構大変だ。なぜなら 解決のための適切な検索クエリを見つけるのが大変 検索結果から今ほしい情報を見つけるのが大変 AIを活用しようにも、コミットログやGitHub Pull Requestと違い、Slackの情報をAIエージェントが直接扱えるやり方が少ない そこでAIエージェントを使って歴史的経緯を発見しやすくするた

今日ははじめてiOSアプリを開発しApp Storeに公開したので告知をします。 僕はその日のやる気を出すために、毎朝やることリストを書き出すということをしていました。この作業をもっと便利にしたいと思い、Daily DoというiOSアプリを作りました。 何をしたかったか 僕はTodoistやAsanaをTODOリストとして利用しています。この2つはやるべきことを忘れないために活用しています。 しかし、これらを使うだけだと、やることはあるけどやる気が起きなくて放置しがちでした。そこで「今日これをやるぞ」というリストを毎朝書き、その日のやる気を出し、1つずつ終わらせていくという習慣にしています。また、このリストは毎日やる気を出すためだけに作っているリストなので、全部終わらなくても良いし、終わらなかったものは次の日には完全に忘れるようにしています。 以前はこの作業をObsidianで行っていて、

AIにブログの下書きを書かせることがあるのだが、出てくる文章が自分の雰囲気とは全然違うものになってしまうという課題があった。「まさにAIに書かせました」という感じの、汎用的で特徴のない文章が出てくることが多い。 自分のブログなので、やはり自分の色をちゃんと出したい。そこで、AIを使いながらも自分らしい文章が書けるような方法を探っていた。 Claude Codeの文脈理解力の高さを活かせば、自分の過去記事から文体を学習させて、それっぽい記事を書かせることができるのではないかと思い、試してみた。 実際にこの方法で書いてもらった記事がこちら： https://blog.shibayu36.org/entry/2025/08/05/173000 。またこの記事自体もClaude Codeで下書きを書かせている。 記事を書かせる前の事前準備 自分の過去記事から文体の特徴を抽出してもらい、WRITIN

LLMのプロンプトエンジニアリング ―GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発 作者:John Berryman,Albert Ziegler,服部 佑樹（翻訳）,佐藤 直生（翻訳）オーム社Amazon LLMアプリケーションを作ることがなかったとしても、業務でAIを活用する上で大前提を知っておくと役立ちそうということで、「LLMのプロンプトエンジニアリング」を読んだ。 実際に読んでみると、紹介されているLLMの特性を知っておくと、AIコーディングなどにもかなり役立ちそうで良かった。 たとえばこの本に載っている以下のような特徴は非常に参考になる。 テキストを一度しか読めず後戻りできない。そのため先に書かれた内容のみを考慮して後に繋げる 気が散りやすい。「うまくいけば」役立つかもしれない無用な情報でプロンプトを埋めないようにする 人間であるあなたが完全に

これまで公式ドキュメントをちゃんと読んだり、Google検索で試行錯誤しながら調べたりしてプログラムを書いているときは、そこで学んだ技術知識はそこそこ自分の頭でも覚えられていた。これは回り道をしながらいろんな情報をかき集めて最終的に自分の頭で考えるフェーズが入っていたからだと思う。 しかし、ChatGPTで技術調査をしたときやClaude CodeでAIコーディングしながら知らない知識を学んだ時、学んだ知識を一瞬で忘れてしまう感覚がある。おそらく高速に知識に到達でき、あまり自分の頭で考えられてないからのように感じる。 もちろん今は知識に高速に到達できるのですべてを記憶しておく必要はない。しかし毎回綺麗さっぱり忘れて、同じようなことをするときに同じだけ調査に時間をかけてしまうのは効率が悪い。なんらかの形で同じようなことをするときはすぐに引き出せるようにしておきたい。 そこで次の作戦を考えた。

最近Cursor、Cline、Claude Codeなどの発展でAIコーディングが進歩し、非常に高速にプログラミングができるようになり、より短時間で機能開発ができるようになってきている。この高速化によって作り出した時間は何に使うべきだろうか？ 僕はこの時間を更なる新機能開発に使うべきではなく、サービスのユーザー理解・既存機能のバグ修正や手触りの改善・エンジニア以外も含めた社内改善に使うべきだと考えている。そのような話を先日Xにポストした。 開発生産性カンファレンスでいろいろ会話する中で、コーディングエージェントによる開発高速化によって作り出したエンジニアの時間は、新機能開発ではなくて、顧客理解・エンジニア以外も含めた社内効率改善・既存機能の手触りやバグ修正辺りに当てるべきだな、という気持ちを新たにした— 柴崎優季 (@shibayu36) 2025年7月3日 今回はこの話について詳しく自分

最近Claude Codeなどのコーディングエージェントによる開発が非常に便利になっていて、何か作りたいなと思ったら今までにないスピードで開発ができるようになった。自分だと https://github.com/shibayu36/mysql-schema-explorer-mcp はCursor AgentやClaude Codeでかなりの部分を開発した。 コーディングエージェントによる開発をいろいろ試して思ったことは、とにかく楽しすぎるということ。自分がこういうものが欲しいなと思ったら、今までにないスピードで魔法のようにできあがる。モノづくりという側面だけでプログラミングを見た時に、面倒な部分をすべてすっ飛ばしてどんどん作れてしまう。この魔法のようにできあがる体験はとにかく楽しい。 一方で、この楽しさは一種の麻薬のようにも感じる時もある。コーディングエージェントによる開発をしていると、

一度ClaudeのMax Planで定額課金状態で、Claude Code + Opus 4を体験してみようと思い、https://github.com/shibayu36/mysql-schema-explorer-mcp で以下の2つをVibe codingしてみた。 e2eテスト作成 データベース固定モード機能開発 結論としては、この規模での開発の場合、ほぼほぼ自分がエディター上で開発をしなくても壁打ちしているだけで開発が終わった。 e2eテスト作成 github.com 機能開発する前にe2eテストがあれば安心できそうなので、まずはe2eテストをVibe codingした。ざっくりと「MCPサーバーをgo runでテスト内で起動し、それに対してstdioでMCP Protocolに沿ったJSONRPCリクエストを投げればテストできそう」ということを伝えた上で開発してもらった。ほぼコ

CursorやClineなどで生成AIを使ってコーディングをしていると、Reasoningモデルとか、Thinkingモードとか、そういったワードに出会うことが多い。これらが意味することについて理解できてないと感じていた。 何かを学ぶとき、資料を読むだけではなく手を動かしてみると理解が早くなる。そこでChatGPTのDeep Researchでハンズオン資料を作り、それを元に学ぶと効率が良いのではないかと考えた。今回の記事ではハンズオンの作成と実施の過程をまとめておく。 ハンズオン資料をDeep Researchで作る 次のように質問してDeep Researchでハンズオン資料を作る。 すると https://chatgpt.com/share/6819d686-5ae0-8010-8196-d532528dc82a のような資料が作られた。 序文 実験の章の一部 見出しはこういう感じ。

最近CLINEに全部賭けろのような記事もあったように、AIエージェントによるコーディングが非常に話題になっている。一方自分は色々試してみるものの、仕事上ではなかなかAIエージェントによるコーディングをうまく使いこなせていない。 ただAIエージェントによるコーディングは置いておいて、エンジニアリングに普通に便利にAIを使えている。それによって数年前と比較するとかなり生産性が上がっている。 そこで今回は自分がエンジニアリングにどうAIを活用しているか、何が便利に思っているかをまとめてみる。 CursorのTabキーによる補完 自分が知りたい技術領域について壁打ちしてもらって作りながら学ぶ コードを読み込んで概要をmermaidで図にする 7割くらいの精度でざっくり理解したい時のコード調査 コーディングエージェントでPoCを作る 枯れた技術の使い方のキャッチアップにChatGPT、新しい技術にP

AIを使ってMySQLのクエリを書くときは、自分が関わっているプロジェクトのスキーマ情報を読み込ませることが必須である。ただし超巨大プロジェクトに携わっていると、特定データベースのテーブル数が数百規模になってしまう。この場合スキーマのダンプ情報を読み込ませるとコンテキスト長が非常に長くなってしまい、失敗することが多かった。 この問題を解決するため、MCPを使ってスキーマ情報をいい感じに圧縮して返すことでSQL生成がもっとうまくいくのではないかと考えた。そこで、テーブル一覧と詳細情報を段階的に取得できるMCPサーバーを、MCPの勉強がてら作ってみた。 作ったもの https://github.com/shibayu36/mysql-schema-explorer-mcp 次のように動く。 実際に大きめなプロジェクトで試したところ、いつもよりうまく生成できるようになった気がする（仕事のプロジェ

GitHub上のOSSにcontributeするためにcommitメッセージやPullRequestのコメントを英語で書くことがある。もう自分で英語を書くのは無理なので自動翻訳を活用したい。この時DeepLなどを使ってもいいのだが、もう少しチューニングを加えたい。たとえば 英語非母語話者同士の会話になることが多いので、できるかぎり平易な表現を使う 1行の場合はcommitメッセージとして、複数行の場合はPullRequestのコメントとして翻訳したい すぐに使えるようにgit commit用のコマンドやMarkdownで出力したい などなど。 そこで最近はChatGPTのProjectsを使って翻訳をしている。 たとえばこんな感じに指示を用意しておいて ソフトウェアエンジニアリングでのコミュニケーションに用いるために和英翻訳をします。以下のことに注意して翻訳してください。 - 英語非母語話

Google Spreadsheetを使っているとき、別のマスターデータシートから特定列だけ読み込みたい時がある。この時簡単に読み込む方法としてはIMPORTRANGEやQUERY関数を組み合わせて使う方法がある。 ただこのやり方だと、マスターデータシートに列が追加された時に壊れやすいという問題がある。QUERY関数などはヘッダー名を指定して読み込むことができず、SELECT Col1, Col3 のような書き方をする必要がある。これだとマスターデータの途中に列を追加した場合に簡単に壊れてしまう。 そこでマスターデータシートのヘッダー名をキーにして読み込む方法を考えてみた。サンプルは こちらのspreadsheetにおいている。 できること 以下のようなマスターデータがあるとして 別シートで一部だけ読み込みたい。この時にマスターデータに列追加しても壊れないようにしたい。 ヘッダー名をキーに

最近はGoの並行プログラミングを学んでおり、ちょうど「Go言語で学ぶ並行プログラミング」という本が出たばかりだったので読んでみた。この本は自分にめちゃくちゃ刺さって面白かった。 Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ 作者:James Cutajar,柴田 芳樹インプレスAmazon この本はGoで並行プログラミングをどうやるかという本ではない。そうではなく並行プログラミングの概念が分かりやすいGo言語を活用することで並行処理の原則や技術を学べる本になっている。そのため、Goを使って独自にRWMutex、Semaphore、WaitGroup、channelを実装していきながら理解を深めていく内容となっている。実装することが一番理解を深める良いやり方と自分も感じているため、とても参考になった。 実際に本を読み