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

こんにちは、mayaです！ 最近、Claude Codeでボリュームの大きいタスクを実行していると、途中でAuto Compactが発動してコンテキストが圧縮され、それまでの経緯をClaude Codeが見失ってしまう問題に悩まされていました。 せっかく良い流れで進んでいたのに、突然とんちんかんな作業を始めるあの絶望感、分かる方も多いのではないでしょうか😭 そんな中、Codex CLIがMCPに対応したという情報を見つけて試してみたところ、これが予想以上に良い体験でした！ Claude Codeがタスク管理役、Codexが実行役という役割分担により、コンテキストウィンドウをほとんど消費せずに大規模なタスクを自律的に完遂できるようになりました。 この記事で分かること / 対象読者 Claude Codeのヘビーユーザー向けの内容です コンテキストウィンドウ問題の実践的な解決方法 Claud

この記事で紹介した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

常々GitHubにtag requestが欲しいと言ってきましたが、それを実現するツールを作りました。OSSなど、バージョニングとリリースが伴うソフトウェア開発のリリースエンジニアリングをとにかく楽にしたいという動機です。既に自分が管理している幾つかのOSSでは導入して便利に利用しています。 https://github.com/Songmu/tagpr アイデア 基本の発想は以下のようにシンプルです。 リリース用のpull requestがGitHub Actionsで自動で作られる バージョン番号が書かれたファイルやCHANGELOG.mdを自動更新 そのpull requestをマージするとマージコミットに自動でバージョンtagが打たれる semver前提 リリース用のpull requestを自動で作りマージボタンを以てリリースと為す、というのは、みんな(僕が)大好き git-pr

世間ではよく、「プロダクトにオーナーシップを持て」というようなことを言われる。かんたんにいうと「このプロダクトは自分のものだ」と思って仕事しろ、という話だ。よく言われるということは、逆にいうと「そうなっていないことが多い」ということだとも思う。つまり、「ほんとうはオーナーシップを持っていてほしいんだけど、そうじゃないから、"持て"と言われる」ということだ。あいさつがあたりまえになされている場所では「あいさつをしましょう」と言われない、というような話。 では、なぜオーナーシップを持つことが難しいのだろう？　ぼくは、いままでいろんな現場を見てきて、いくつかのアンチパターンがあるな、と思っている。 アンチパターンの解説から入るまえにまず、前提の話から。そもそも、ソフトウェアエンジニア自体が「オーナーシップなんか持ちたくないよ」と思っている場合、それはどうやってもオーナーシップを持たせることは不可

こんにちは、Algomatic AXの大塚（@ootsuka_techs）です。 本記事では、いま話題の仕様駆動開発（Spec Driven Development; SDD）を調べ、社内で試した学びをまとめます。 今回は以下の4つのツールを使用し、それぞれの特徴や使い勝手を詳しく検証しました。 Kiro Spec Kit spec-workflow-mcp cc-sdd 比較した結果は以下の通りです。 機能比較表 機能 Kiro Spec Kit spec-workflow-mcp cc-sdd 日本語対応 △ △ ○ ◎ 承認フロー ○ ○ ◎ ○ プロジェクトガバナンス ○ ◎ ○ ○ IDE統合 ○（専用IDE） ○ ○ ○ オープンソース × ○ ○ ◎ エンタープライズ対応 ◎ ○ ○ ○ 学習コスト △ ◎ ○ ◎ カスタマイズ性 △ ○ ○ ◎ 以降は仕様駆動開発（Spec

GPT‑5 Codexがリリース OpenAIが2025年9月15日にGPT‑5 Codexを発表しました。GPT‑5 CodexはGPT‑5を土台にして、エージェントのコーディング能力に適した学習と強化が加えられたモデルです。長時間の自律的な作業に特に強みがあります。 We’re releasing new Codex features to make it a more effective coding collaborator: - A new IDE extension - Easily move tasks between the cloud and your local environment - Code reviews in GitHub - Revamped Codex CLI Powered by GPT-5 and available through your Cha

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

2025.09.22 7:40 全体的にイエス・バッド法になっていたところをイエス・アンド法に書き換えました。身についてないなぁ はじめに たびたび話題になる「技術的には可能です（でも影響範囲でかいし、品質に影響与えそうだし、結構コストかかるし、スケジュールきついし・・・無理じゃね？）」問題ありますよね。 口に出したことより、心の中の声の方がでかいみたいな。 そしてこれは、言われた側からは非常に不評でもあります。 私は比較的最近、この問題とうまく付き合えるようになりましたので、少しアイデアを共有したいと思い、この記事を書きました。 解決策 それは「できる」と「やる」を分離して できる：自分の責任 やる　：相手のバトン（責任） とすることです。 「はい、できます。リリーススケジュール調整が必要になりますが、やりますか？」 「はい、できます。追加コストが発生しますが、やりますか？」 「はい、で

自分の文体に近い形式でAIにブログ記事を書かせることはできるのだけれど、なんだかあまりそうしたくない気持ちがあり雑に考えを書いておきたい。 自分の場合、ブログを書き始める時点では内容の結論が明確になっていないことが多い。 なんとなく困っていたり課題に感じていたり、逆にすごくいいなと思っていたり真似したいなと感じていたりすることを深ぼっていく。そうするとだんだんと「こういうことかもしれないな」とわかってきて、最後にタイトルを決めて吐き出している。 その過程で色んなことを考えて行ったりきたりして自分の考え方が整理されていく中で、"美学"や"信念"みたいなものなんかも見えてくる感覚がある。 この出力プロセスをAIに任せるのはよくないというか、そこを任せて何の意味があるのかと感じてしまうのである。 自分にとっては色々と幅を広げて考えるプロセスを経てから考えを深めていくこと自体に意味がある。もちろん

今年に入ってやたらレビューの時間が増えた。これはコードもそうだしドキュメントもそうだ。 そして、これによる疲れも急激に増加している。 もちろんこれは、LLMによる支援によってアウトプットの速度と量が増加したからだ。 そして、必ずしも質が向上しているわけではなく、むしろ下がっているように感じる。 当然、自分の生産性も下がっている。 自分の頭をダンプし、どういう課題があるか、そして、どう向き合っているかを書いていこうと思う。 他人を経由したプロンプティング私は、機械学習のプロジェクトのテックリードとしてしばらく働いている。 その仕事として、Engineering Requirement Documentsなどの技術文章を書くことも多いが、レビューする機会も多い。 機械学習で難しいのが、プロジェクトが変わり解く課題がちょっと変わると、がらりと全然違う知識が必要になり、新規に論文を読む必要が出てく

Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志

はじめに 最近、Claude Code を使って「設計 → 実装 → テスト → PR」という流れを丸ごと自動化できないかと考え、検証用のプラットフォームを作っていました。 このプラットフォームは YAML ファイルでサブエージェントを制御し、ワークフローを実行する仕組みです。 ただ実際にやってみると、サブエージェントを順番に実行していくことは意外と面倒 だと気づきました。 そこで「もっとシンプルにワークフローを定義できる仕組みが欲しい」と思い、「CC-Flow」 を作りました。この記事では、その仕組みと使い方を紹介します。 なぜ作ろうと思ったか Claude Code でワークフローを組む際、当初はサブエージェントを順に呼び出すことで実現できると考えていました。 しかし実際に使ってみると、次のような課題がありました。 YAML ファイルが膨大になり、管理が大変 呼び出し順を変えるだけでも

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

たくさんの応援ありがとうございました。 また、普段の連載を支えてくださる多くの方々にも感謝します。 声援を胸に、これからも精進する所存です。 最後に阿川監督にも感謝を。 監督がたくさんの読者を呼んでくれたと思っています。 締切が迫る中、監督をどうしようかと悩んでいる時に趣味で描いていた落書きを見返して彼女が生まれました。 (住吉九)

Published Sep 17, 2025 This is a technical report on three bugs that intermittently degraded responses from Claude. Below we explain what happened, why it took time to fix, and what we're changing. Between August and early September, three infrastructure bugs intermittently degraded Claude's response quality. We've now resolved these issues and want to explain what happened. In early August, a num

生成 AI において、グラウンディングとは、モデルの出力を検証可能な情報源に紐付ける仕組みを指します。特定のデータソースにアクセスできるモデルを用意することで、グラウンディングによりその出力が特定のデータに紐づけされ、コンテンツのねつ造が起こりにくくなります。これは、精度と信頼性が重要な状況で特に重要です。 グラウンディングには次の利点があります。 モデルのハルシネーション（モデルが事実に基づいていないコンテンツを生成すること）を削減します。 モデルのレスポンスをデータソースに固定します。 引用と信頼スコアを提供することで、生成されたコンテンツの信頼性と適用性を高めます。 Vertex AI では、サポートされているモデルの出力を次の 2 つの方法でグラウンディングできます。 Google 検索によるグラウンディング データへのグラウンディング（プレビュー）。 言語のサポートについては、プ

メインブラウザをEdgeに切り替えた理由とAIブラウザの可能性 ChromeからEdgeに乗り換え最近、筆者はAI統合型のブラウザを常用するべくメインブラウザをGoogle ChromeからMicrosoft Edgeに切り替えました。EdgeのCopilot Modeは8月にGPT-5が搭載され、かなり使い勝手が良くなりました。2年前にこの前哨戦となる「Bing AIチャットをデフォルトのウェブ検索にして使ってみた」を投稿したのですが、当時と比べると雲泥の差です。 この記事では、筆者がEdgeへの移行を検討するに至った背景や、実際の使用感について整理しました。また、AIブラウザの台頭に伴い、セキュリティ面での新たなリスクについても考えることになったのでそれを喚起します。 移行の動機筆者がメインブラウザをChromeからEdgeに移行した最大の理由は、AI統合型のウェブブラウジングを日常に

MCP では stdio と Streamable HTTP の 2 つの transport が定義されています。TypeScript SDK では v1.10.0 から Streamable HTTP transport がリリースされました。この記事では MCP サーバーを構築し、Streamable HTTP transport を試してみます。 MCP（Model Context Protocol）では JSON-RPC を使用してメッセージをエンコードしています。クライアントとサーバー間のトランスポート方式として以下の 2 つが定義されています。 stdio: 標準入出力を介した通信（主にローカル実行向け） Streamable HTTP: HTTP ストリーミングを介した通信（リモートサーバー向け） 現在（2025 年 4 月時点）では、多くの MCP クライアントとサーバー