Qiita Conference 2026 https://qiita.com/official-campaigns/conference/2026
LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント(特にClaude Code等)の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか? 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テストで時間とコストを節約する」 筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として7つの原則があります。その中の1つとして「早
はじめに こんにちは!Acsim 開発チームの笹沢です。 AI 駆動開発の浸透でコードの生産量は飛躍的に増えました。一方、人間がレビューに割ける時間は変わらないため、レビュー待ちで PR がスタックする場面が以前より増えていきました。 私たちのチームでは「人間のレビューを必須とするもの」と「AI レビューで OK とするもの」を線引きし、セルフマージ制度として日々の開発に組み込みました。直近では PR の 約 8 割が人間レビューを介さずにマージできています。マージまでのリードタイムも短縮されています。 この記事では、セルフマージ制度の設計と運用上の工夫、導入後の変化を紹介します。AI レビューが十分使えるレベルになった今、自チームのレビュー運用を見直したい方の参考になれば嬉しいです。 すべての PR に人間レビューは必要か 最近の AI レビューはコード品質の担保という意味では十分使える
社内のチームメンバー(クラウド事業本部コンサルティング部)向けに 「 Claude Code を安全に使おう勉強会 」を開催しました。 Claude Code をセキュアに使う上での、 基本的な考え方や権限/サンドボックス機能の紹介、簡単なデモを実施しました。 DevelopersIO向けに調整したスライドを掲載します。 以下勉強会で連携した設定サンプルです。 Claude Code を安全に使おう勉強会: 補足資料 - Gist スライドの内容:テキスト情報を以降に記載します。参考になれば幸いです。 イントロ 勉強会の目的やアジェンダ、スコープについて話します。 勉強会の目的 Claude Code (に限らず、AIエージェント) はとても便利です。 しかしリスクもあり、暴走もします。 この勉強会では、 Claude Codeが適切な範囲で適切に動けるような、 ガードレールの敷き方 を学
AIセーフティを標榜するAnthropicが、ビルド設定ミスで自社ツールのソースコードを丸ごと公開してしまった。未公開機能やロードマップが露出し、セキュリティ管理の教訓として記録に値する。 この記事ではClaude Codeに特化して解説します。Claude Code全般は Claude Code完全ガイド2026:インストールから本番運用まで をご覧ください。 Claude Codeソースコード流出の経緯 ── npmソースマップ混入事件 Anthropicが提供するAIコーディングツール「Claude Code」の中身が丸見えになった。 ハッキングされたわけではない。Anthropicが自分でnpm(JavaScriptのパッケージ管理システム)にコードを公開するとき、「ソースマップ」という本来含めてはいけないファイルを一緒に入れてしまった。いわば設計図を製品と一緒に箱に入れて出荷して
前回の記事「PMはスキルエンジニアリングを極めるべし」では、PMが今やるべきはモデル競争を追いかけることではなく、自分の業務をSKills化する力を磨くことだという話をしました。 今回はその続きで、「じゃあ実際にどうやってスキルを作るの?」という具体的な方法を解説していきます。エンジニアではない方でも作れるように、考え方から手順まで丁寧に書いていきます。 そもそもSkillsとは?Skillsは、よくやる作業手順や知識をまとめた「スキルファイル群」を作っておくと、AIがそれを読み取って実行してくれる仕組みです。 今回はClaude Codeを使った作り方を解説しますが、SkillsはClaude Code固有の機能ではありません。CodexやCursorなど、他のAIコーディングツールでも同じ考え方で進められます。スキルの設計や構成の仕方は共通なので、ツールが変わっても応用できます。 スキ
ポイントは、これらが一回のプロンプトの工夫ではなく、 プロジェクト全体の「環境」として蓄積される ことです。調べていくうちに気づいたのは、これらのテクニックに共通するパターンがあるということ — ポッドキャストではこの考え方を「 複利的エンジニアリング 」(筆者訳、原文では compounding という表現)と表現していました。使えば使うほどClaudeが賢くなる構造だと言えそうです。 参考:2026 Agentic Coding Trends Report、Anthropic公式ブログ 2. コードを書く前の戦略を使い分ける Claude Codeに、いきなり「実装して」は効率が悪いとのことです。ただし、計画の立て方にも複数のアプローチがあり、 ゴールが明確なときと、何が必要かまだわからないときでは戦略が異なります 。 ゴールが明確なとき → Plan Mode "If my goal
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさん、ClaudeCodeを使っていますか? (「バチバチ使いこなしているぜ!」という方は読んでも意味ないので、この記事は閉じてください!) 私はClaudeCodeが好きで、業務はもちろん日常生活でもほぼ毎日使っています。なるべくClaudeCodeに仕事をさせるように、設定やSkillを日々いじくり回しています。 ただ、ClaudeCodeは便利な反面、難しいツールでもあります。難しい理由は「機能の豊富さ」と「爆発的なアップデート速度および頻度」から来ていると思っています。気を抜くとすぐに自分の知らない機能が増えています。私もな
Claude Code使ってると「あれ、前のセッションどこ行った?」ってなることありませんか? 実はClaude Code、デフォルトだと30日間非アクティブなセッションは起動時に自動削除されるんですよね。知らなかった…。 ってことで、設定を調べて9999日(約27年)に変更してみました。 💡 保存期間は2種類ある ここがちょっとややこしいんですけど、Claude Codeのデータ保存にはサーバー側(Anthropic)とローカル側(端末)の2種類があります。 ▼ サーバー側(Anthropic) プランと条件によって保存期間が変わります: ・Free/Pro/Max + モデル改善OFF → 30日 ・Free/Pro/Max + モデル改善ON → 5年 ・Team/Enterprise/API → 30日 ・API + Zero data retention(ZDR) → 保存なし
この4ドキュメントを使うと、品質を落とさずに速く仕事を進められるようになります。 PLAN.mdで「音声入力」が最重要な理由 この中で特に大事なのが、最初のPLAN.mdで自分の考えを全部ダンプすることです。そしてそのために音声入力が欠かせません。 LLMにドキュメンテーション系の仕事(資料作成、記事執筆、提案書など)をやらせるとき、少ない情報で動かしてしまうと、人間が思ってもいないことをどんどん生成してしまいます。これが「AIが書いた感」の正体です。 逆に、自分が思っていることを全部ダンプした上で「詳細の整理と日本語の微調整をやって」と頼むと、クリエイティブな仕事であっても「AIが勝手に生成した」という感じになりにくい。あくまで自分の考えの細部をClaudeに整えてもらった、という仕上がりになるので、100%手書きしたときと比べてアウトプットの品質が落ちにくいです。 ただ、この「全部ダン
はじめに AIで開発は本当に速くなったのか? 「AIを使えば開発が速くなる」 このフレーズ自体は、もう聞き飽きるほど目にしてきました。 実際、コード補完は賢いし、ちょっとした関数やエラー修正なら一瞬で解決することもあります。 でも本当に“開発全体”は速くなりましたか? コードを貼り付けて修正してもらう。 生成されたコードをコピペする。 動かない。 足りなかった前提を説明し直す。 気づけば、コンテキストの説明に時間を使い、差分の確認に神経を使い、結局自分で修正する。 そんな経験ないでしょうか? AIは優秀ですが、「ワークフローに組み込まれていないAI」は、強力な検索エンジンとあまり変わりません。 私はClaude Codeを個人開発に導入する際、プロンプトを工夫するのをやめて、AIが迷わない構造そのものを設計することにしました。 その結果、Issue作成、実装、PR作成までを一貫して任せられ
結論 「テストして」って言っただけなのに、AIが自分でバグ見つけて、自分で直して、「違反は切腹」ってルールを自分で追加してきた。 人間、何もしてない。 何を作ったか Claude Code × tmux でホワイトカラー向けマルチタスクツールを作った。 名前は multi-agent-shogun。 戦国時代の軍制をモチーフに、将軍1名・家老1名・足軽8名の階層構造でAIエージェントを統制する。 上様(人間) ↓ 「やれ」 将軍(Claude Code) ↓ 「家老、タスクを分解せよ」 家老(Claude Code) ↓ 「足軽ども、並列で実行せよ」 ┌──┬──┬──┬──┬──┬──┬──┬──┐ │1 │2 │3 │4 │5 │6 │7 │8 │ ← 8人同時に動く └──┴──┴──┴──┴──┴──┴──┴──┘ 足軽(Claude Code × 8) とにかくshogunにぶち
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
コマンドラインからさようなら!Claude Codeの視覚的なワークフロー編集器が人気:ノードをドラッグ&ドロップするだけでAI自動化ツールを構築 2025年末、AnthropicのClaude Codeが重要なコミュニティエコシステムの突破を遂げました。VSCode拡張ツール「Claude Code Workflow Studio」が急速に人気を博しています。このツールは直感的なドラッグ&ドロップ式のキャンバスインターフェースを通じて、複雑なプロンプトやターミナルコマンドを書かずに、高機能なAIオートメーションワークフローを構築・実行することが可能です。これにより、Claude Codeは純粋なコマンドラインツールから視覚的でノーコードへの進化を遂げ、非専門開発者にとっての使用ハードルを大幅に下げました。 主な機能:ノードのドラッグ&ドロップで複雑なプロセスを作成 Claude Code
Googleは2025年11月13日(米国時間)、ソフトウェア開発における「コード読解」の負担を軽減する新サービス「Code Wiki」のパブリックプレビュー版を公開した。同社は、「既存コードの理解に時間がかかることが開発の最大級のボトルネックになっている」と指摘し、この課題を解決する仕組みとして本サービスを位置付けている。 コード全体を自動解析して常時更新するだけじゃない、Code Wikiの機能 今回公開されたWeb版Code Wikiは公開リポジトリ全体をスキャンし、コード変更のたびにドキュメントを自動生成する仕組みを備える。静的ファイルではなく、常に最新状態に同期される構造化Wikiを維持する点が特徴だ。ドキュメントはコードの構造や役割に基づいて整理され、変更のたびに自動で刷新される。 生成されたWikiは、全てのセクションにコードへのハイパーリンクが付与されており、説明文から関連
この記事では最近(2025/08時点)でKurogoma4DがClaude Codeを使うときにどういうフローで使っているかという話をしていきます。 既存プロジェクトの調査のとき serena MCPを導入する 調査結果はMarkdownに出力してもらう serena MCPを導入する 最近話題のやつです。プロジェクトの構造や依存関係を素早く把握できるので、既存プロジェクトに初めて触る時は特に重宝します。 調査結果はMarkdownに出力してもらう 「このプロジェクトの認証フローを調査してMarkdownにまとめて」のように依頼すると、なにかしらの調査レポートが得られます。これを最初からplan modeではなくedit modeでやらせるのが肝です。 結果をファイルとして書き出しておけば、その時点で外部メモリとして機能させることが可能なので、ブラッシュアップがしやすくなります。 また、こ
経験の浅い人にちょくちょくするアドバイスとして、「コードリーディングのときにはあんまコードを読まないほうがいいよ」がある。コード全体を詳細に読むのではなく、名前やインターフェイスからコードの意図を把握することで効率的にコードリーディングできる。完全に下記の受け売り。 「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係のグラフを書いたりして。実装はちゃんと出来ていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにするんです。そっちの方が、実装を見るよりずっと楽ですよね。」 牛尾 剛「コードリーディングのコツは極力読まないこと 」 自分なんかは、エディタの畳み込み機能と変数名ホバーを使って、名前とインターフェイスしか見えない状態で読む。中身を読みたいなーと思ったところは畳み込みを解除して徐々に読ん
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 7 Gems Which Will Make Your Rails Code Look Awesome 公開日: 2017/10/14 著者: Val Zavadskiy サイト: https://blog.rubyroidlabs.com/ Rubyroid Labsの別記事「Ruby on Railsで使ってうれしい19のgem(翻訳)」も合わせてどうぞ。 私たちRubyroid Labはアプリのアーキテクチャに多くの情熱を注ぎ込んでいます。手がけているプロジェクトの多くが長期にわたっているので、設計のどこかで少し油断すると、機能を1つ追加するのにプロジェクトをスクラッチからやり直す方が早い、といった事態になりかねません。こんな目には遭いたくないものです。 新しく参加したメンバーがロジック把握のためにソースコードを読みとおすだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く