こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agent時代の開発ワークフローについて、みんながやっているものからわたしがやっている手法までまとめて紹介していきたいと思います。 前回の記事 Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス では、LinterやHooks、テスト戦略といった決定論的ツールでCoding Agentの出力を矯正するHarness Engineeringに特化しました。 今回はその上位にある問い、つまりハーネスは分かったけど全体としてどう開発を進めればいいのか、に答えます。プロジェクトの進め方、Agentとのコーディングテクニック、それを支えるインフラの3つの視点から2026年3月時点の状況を整理し、最後にわたし自身のワークフローも紹介します。 Agenti

ポイントは「強制力」の違いです。プロンプトでいくら「anyを使うな」と書いても、エージェントは忘れます。一方、リンターでブロックすれば物理的に使えません。 Stripe Minionsチームの言葉が本質を突いています。 優れた開発者インフラを構築せよ。エージェントは自動的にその恩恵を受ける。 エージェント専用のインフラを作るのではなく、人間の開発者にとっても良い環境を作る。それがそのままエージェントの性能を引き上げます。 Stripeの事例では、人間用に構築した開発環境（devbox）をそのままエージェントに使わせています。エージェント専用の特別なツールを作ったわけではありません。良い開発者体験は、良いエージェント体験でもあるということです。 実装1: 50行CLAUDE.mdの設計 ポインタ設計の原則 逆瀬川ちゃんの記事でも強調されていた原則があります。「CLAUDE.mdはポインタであ

前回記事から1ヶ月くらい経ったのでその間に得られた知見からの所見を述べる。 やっぱり実装に関するドキュメントはいらん。仕様は全てコードにある。コードをSSoT(Single Source of Truth)とすべきだ。ドキュメントとコードの二重管理はコストが大きすぎる。特にドキュメント側の管理コストが大きく、どれだけagentにドキュメントを修正しろと指示を出してもドキュメント修正の実行が確率的であるし、ドキュメントを更新するトークン数が無駄。コード読めばわかることを自然言語にわざわざ起こさんでいい。仕様がわからんくなったらclaudeに聞けばいいのでドキュメントを永続化する必要性が皆無すぎる。ドキュメント書かせるくらいならclaudeさんに感謝のメッセージを送った方がいい。限りある電力を無駄にするな。結論として仕様駆動開発はウソです。少なくともおれにとってはウソでした。手間の割に効用を実

Today we're introducing Code Review, which dispatches a team of agents on every PR to catch the bugs that skims miss, built for depth, not speed. It's the system we run on nearly every PR at Anthropic. Now in research preview for Team and Enterprise. Managing the review bottleneckCode output per Anthropic engineer has grown 200% in the last year. Code review has become a bottleneck, and we hear th

連載目次 Anthropic公式が提供するオンライン講座「Anthropic Academy」に、AI開発ツール「Claude Code」などで利用できる新しい概念「エージェントスキル（Agent Skills）」を解説するコースが追加された。動画の公開日から判断すると、このコースは最近（2026年3月初旬ごろ）公開されたものとみられる。なお、このコースは無料で受講できる。 エージェントスキルとは、Claudeに特定のタスクを実行させるための指示や処理手順を「スキル」として定義し、必要な場面で再利用できる仕組みである。これにより、毎回同じプロンプト（指示文）を書く必要がなくなり、AIエージェントの作業を効率化できる。 Claude Codeでは、エージェントスキルという仕組みにより、よく行う作業の手順や指示を「スキル」としてあらかじめ定義しておき、必要なときに呼び出して実行できる。例えば、

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

はじめに 「Skillを自作したいけど、毎回ゼロからSKILL.mdを設計して詰む」 Claude Codeを使っている方なら、一度はこの壁にぶつかったことがあるのではないでしょうか。 Anthropicが公開している skill-creator は、まさにこの問題を解決するための「Skillsを作れるSkills」です。自然言語で対話しながら、Claudeが自動でSkillのフォルダ構成・SKILL.mdファイル・必要なスクリプトを生成してくれます。 この記事では、skill-creatorの導入から実際の使い方、そして活用時の注意点までを体系的に解説します。 この記事で解決できる課題 SKILL.mdの書き方がわからない Skillのディレクトリ構成で毎回迷う 作ったSkillがバリデーションエラーで動かない Progressive Disclosure（段階的開示）の設計原則が理解で

概要 こんにちは！PeopleX　AI面接を開発しているせりせり(@seriseri_55)です！みなさん開発組織内でのAI活用は上手くいっているでしょうか？ 先日keitaknさんによる技術負債も理解負債も生まないAIコーディング手法を読みました（めちゃくちゃためになった）。その中で「最初に実装計画をAIに立てさせる」という話が紹介されていたのですが、弊チームでも 実装前にAIにデザインドキュメント（設計書）を書かせることで、AI活用の恩恵を強く感じるようになりました。 本記事では、その取り組みについて Before / After、実体験、具体的な活用方法 を私目線で紹介します。 結論 AIにデザインドキュメント（設計書）を生成させる 生成させたデザインドキュメントをチームでレビュー レビューしたデザインドキュメントを元にAIに実装させる このプロセスを踏むだけで、チームメンバーの理解

ちゃんと人間が書いています。 Claude Codeをこれから使い始める初学者の方から、 すでに使っているけれど もっと活用したい上級者の方まで、 幅広く対象にしています。 2026/02/18時点のAnthropic公式のベストプラクティスと、私の開発の知見を元にまとめています。 上から順に読んでいけば、誰でもプロになれるように書きました。

ジャンプTOON ソフトウェアエンジニアの國師 (@ronnnnn_jp) です。 この記事では、仕様書の作成・レビューに生成 AI を活用するための実践的なアプローチを紹介します。 目次 生成 AI による開発効率の変化 LLM の特徴と制約 コンテキスト情報の整備 手順や制約の明確化 評価と効果 なぜ Notion AI か おわりに 生成 AI による開発効率の変化 2024 年 5 月にサービスを開始したジャンプTOON は、モバイルアプリケーションと Web ブラウザアプリケーションを提供しています。バックエンドも含め、ジャンプTOONの開発は大きく次の流れで進みます。PM が企画と仕様策定を行い、開発メンバー (エンジニア、デザイナ、QA など) を巻き込んで仕様をブラッシュアップします。その後、デザイナが UI デザイン、エンジニアが実装を進めます。 昨今ではコーディング A

はじめに 先日、あるスタートアップがシステムを作り直すという文脈の中で「LangChain を採用」という記述があり、X で疑問を呈したところ「LangChain v1 で大幅に改善された」「批判は古い印象に基づいている」「根拠のない批判だ」という反論がありました。 では実際にソースコードを読んで確認してみよう、というのが本記事の趣旨です。 私自身、2年前は LangChain をメインで使っていました。 当時は生成 AI の最適解がまだ見えておらず、各社 SDK のインターフェースも頻繁に変わっていた時代です。そんな中で LangChain のようなラッパーは、コンテキストスイッチを減らし、プロトタイプを素早く回すには一定の価値がありました。 しかし 2026 年、状況は変わっています。 各社 SDK のインターフェースは安定してきた AI がどの SDK のコードでもすぐ生成できる 実

2026/1/29 DIST.52 「今から始めるClaude Code超入門」

LLMによるコード補完の登場 (2021年) GitHub Copilotの登場 我々がよく知るLLMによる支援はまず GitHub Copilot から始まりました。これはGPT-3 (OpenAI Codex, 現在のCodexと名前が同じで本当にややこしい) をベースとしたコード補完システムで、タイピングをしていると自動的にその行の続きを予測してくれるものです autocompleteとの違い それ以前にもIntelliSenseのようなautocompleteがありましたし、より進歩したn-gramなどを用いたものはありましたが、LLMをベースとしたものはTabnine (Tabnineは初期はn-gramモデル) やCopilotからとなります チャットベースのコードアシストの時代 (2022-2023年) ChatGPTの登場 ChatGPT以降、チャットによる対話形式でコード

Anthropicハッカソン優勝者が10ヶ月以上かけて実際のプロダクト開発で使い込んだ everything-claude-code というリポジトリが公開されていたので、内容を読み解いてみました。 この記事の要約 Anthropic x Forum Venturesハッカソン優勝者 が公開した本番環境で使えるClaude Code設定集 agents, skills, hooks, commands, rules, MCP設定 の6種類のファイルで構成 コンテキストウィンドウは 200kから70kまで縮小する可能性 があるため、MCPの有効化は10個以下に抑える TDD（テスト駆動開発）を中心 にしたワークフローで、カバレッジ80%以上を必須とする /tddや/planなどの スラッシュコマンド で素早くワークフローを呼び出せる hooksによる自動化 でフォーマット実行やconsole

KDDIのグループ会社でシステム開発を手掛けるKDDIアジャイル開発センター（KAG）が、「仕様駆動開発」と呼ばれるシステム開発手法を2025年9月から導入した。AIを活用して仕様書を作成し、その仕様書に基づいてソースコードを生成する。同手法の採用によって、従来は「設計2割・開発8割」だった業務内容が「設計8割・開発2割」に激変したという。 KAGは2025年9月から、アプリケーションにSMS（ショート・メッセージ・サービス）の機能やプッシュ通知の機能を提供するAPI（アプリケーション・プログラミング・インターフェース）基盤を開発する業務に、仕様駆動開発を導入した。 仕様駆動開発は、米Amazon Web Services（アマゾン・ウェブ・サービス、AWS）が2025年7月にプレビュー版をリリースしたAIエージェント型のIDE（統合開発環境）である「Kiro」で提唱されたシステム開発手法

“音声入力は使えない”派が認めた「Aqua Voice」とは？　2026年、プログラミングの常識が変わる：Deep Insider AI Practice 「音声入力は使えない」と思い込んでいた私が、1カ月使って考えを改めた理由。AIコーディング時代のプログラミングでは、入力そのものの常識が変わり始めています。Aqua Voiceを実際に使い込んだ体験から、その実力と使いどころを正直に紹介します。 連載目次 「音声入力？　どうせ誤変換だらけで、修正の手間の方がかかるでしょう」 2025年12月まで、私は本気でそう思っていました。正直に言えば、音声入力ツールを全く信用していなかったのです。キーボードで手入力した方が、結局は速くて確実だと信じて疑っていませんでした。 理由は単純です。私は話すのがあまり得意ではありません。文章なら考えながら言い回しを調整できますが、話す場合は、言葉を口に出した時

【まとめ】2025年の学び年間サブスクは罠。AI情勢はすぐ変わる 「最強モデル1つ」より「適材適所」 「入り口」で体験が大きく変わる 魔改造は無駄になる。「軽さ」こそ正義 Gitを制する者がAIコーディングを制す ログとTDDだけで8割の問題は解決する 雑にしゃべり、AIに整理させると効率いい 「AIは賢いから大丈夫」は危険 拡張機能を詰めすぎると低脳に AIコーディングは「ディレクション」 2025年は「AIコーディング元年」と言っても過言ではないくらい、大きな変化がありました。Claude Codeの登場により、AIが自律的な作業をおこなえるようになり、非エンジニアでもかなりコーディングがしやすくなりました。 私自身、非エンジニアではありますが暇さえあればAIコーディングで何かを作るように。もはや「これなしでは考えられない」くらいの存在です。 この1年を振り返り、AIコーディングをより

2023年から段階的にAIを開発フローに組み込み、2025年は試行錯誤とツールの大きな変化、そしてエージェント化を経て、私のソフトウェア開発の進め方は明確に変化しました。 ここで言う「変化」とは、単に作業が速くなった、便利になったという話ではありません。 より具体的には「コードをタイピングする時間よりも、間接作業の比重と抽象的な思考・ロジックが増えた」という意味での変化です。 とりわけ深刻なのは文字入力回数の増大です。その結果、マイクに向かって話したり、タイピングの練習といったプリミティブな活動を取り入れるようになりました。 この変化は私だけのものではありません。Addy Osmaniは『Beyond Vibe Coding』で「開発者の役割はコードを書くことから、コードを指示すること（directing）へシフトしている」と述べ、アーキテクチャやデザインパターンといったシステム思考への集