こんにちは、ナレッジワークのソフトウェアエンジニアの石川宗寿 (munetoshi) です。 この記事は、KNOWLEDGE WORK Blog Sprint の第 27 日目の記事です。 TL;DR: スケルトンコード (型や関数の枠組みだけ定義した未実装のコード) を書くときは、「未実装であること」を確認するテストも一緒に書くことをおすすめします。私はこれを「スケルトンテスト」と呼んでいます[1]。 スケルトンテストを書いておくことで、「コードを実装したにもかかわらずテストを更新しなかった場合に、テストが失敗する」という状況を作れます。結果として、開発者は実装時にテストコードの修正を強制されるわけです。 はじめに: スケルトンコードとは？ スケルトンテストの前に、スケルトンコードについて説明します。 スケルトンコードとは、型や関数の名前、引数/戻り値、依存関係だけを先に定義し、具体的な

より速いマージのための、大きな動き 私たちは、AIを使った開発のあり方を再定義するような大きなニュースを発表しました。 CodeRabbit CLI（こちらから利用できます)をローンチし、シリーズBで6,000万ドルを調達。さらに、オープンソースへの支援を拡大し、100万ドルのスポンサーシッププログラムを発表しました。 加えて、MCPサーバー統合によって、レビューにさらに多くの「コンテキスト」を提供します。まさに盛りだくさんの動きです！ CodeRabbit CLI: AIレビューを、あなたのターミナルに このCLIツールにより、私たちはIDE、Gitプラットフォーム、そしてコマンドラインインターフェイス全てでAIコードレビューを提供する唯一のプラットフォームとなりました。 CodeRabbit CLIは、プロダクションレベルのコード解析をターミナルに直接提供し、コミット前に問題を検出でき

「AIがコードを書く時代、スクラムは本当に最適解なのか？」 この問いに、あなたは即答できますか？ 開発現場で起きている静かな革命 AIによるコーディングが当たり前になりつつある今、ソフトウェア開発の進め方そのものを見直すタイミングが来ています。 多くのチームがスクラムを採用していますが、AIが主導する開発（AI駆動開発）では、実はウォーターフォールの方が合理的なのではないか？ という問いが浮かびます。 ただし――速度は従来のスプリント並み。つまり、「遅いウォーターフォール」ではなく、「Water-Scrum-Fast」という新しい形が現実解です。 スクラムがAI駆動開発に噛み合わない理由 AIによる実装は、以下のようなサイクルで進みます： このサイクルは極端に短く、AIが生成するコードは**「曖昧な仕様」に敏感**です。そのため、要件や非機能要件をしっかり定義しておかないと、AIは暴走しま

こちらは primeNumber AI Native Summer Calendarの記事です。 本日の担当は、CTO の kekekenta (@kekekenta) です。 他の記事も読みたい人は カレンダー を見てください！ はじめに インシデントの再発防止策として「レビューで注意する」「チェックリストに追加」といったアクションを決めても、時間とともに形骸化してしまう経験はありませんか？ TROCCO/COMETAの開発チームでは、AIエージェント（Claude Code）を活用して、過去のインシデントから学んだ知見をもとに、AIのレビューで事前に問題を検知することを試しています。 課題：人の記憶に頼る再発防止策の限界 primeNumber では、インシデントやヒヤリハットが発生した場合にポストモーテムを実施し、再発防止のアクションを決定しています。しかし、以下のような課題がありま

初めまして、kagayaです。 AIネイティブなプロダクト開発を頑張っています。 共訳した「AIエンジニアリング（オライリー・ジャパン）」が11/28に発売です。よろしくお願いいたします。 世はAIコーディングエージェント時代。 圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。 かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。 そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ？ です。 全部読んでたら、自分で書いた方が早くない？でも全部信じるのも怖い。 バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。 Thoughtwo

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

Platform Engineering Kaigi 2025のセッションスライドです。

みんチャレを開発している山本です。 日々みんチャレを開発する中で、みんチャレ開発チームのコードレビューは、品質向上だけでなく、チームに安心感をもたらしているなと感じています。そこで今回は、私たちみんチャレ開発チームがコードレビューを大切にする理由と、より良いコードレビューのために工夫していることを紹介したいと思います。 コードレビューを大切にする理由コードレビューを大切にしているのは、みんチャレ開発チームでのコードレビューが以下のことにつながっているためです。 1. 品質向上 コードの読みやすさや拡張性、要件や仕様の確認、抜け漏れがないかについてメンバー間で議論を行い、プロダクトの品質を高めています。 2. 学び合いの場 レビューを通じて、メンバー間で知識が共有され、互いに学び合う場になっています。コメントでエレガントな書き方を知ることができたときは、そのコメントに👍️や♥️を付けたくな

これからのコードレビュー：その1「AIと人間が共存するコードレビュー」の続き。 コードレビューは品質を守るためのチェック工程だと捉えられがちですが、本質はそれだけではありません。レビューは開発者同士がコードを読み合い、知識や考え方を交換する文化的な工程でもあります。 多くの開発現場では、バグを見つけることやコーディング規約に沿っているかを確認することに注目しがちです。しかし実際には、レビューを通じてメンバーが他人のコードを読み、設計意図や背景を理解する過程こそが大きな価値になります。新人は設計の勘所を学び、経験者は異なる視点からの気づきを得られます。また、ビジネス要件やドメイン知識の共有にもつながります。 つまり、レビューを文化育成の場として捉えることで、単なる品質保証の手段から、組織全体の学びと成長を支える基盤へと意味づけられるようになります。本記事では、その文化を形づくる「読む」という

The vibe coding's impact: How AI-driven development is transforming the tech industry 音声や簡単なテキスト指示だけでAIがソフトウェアを自動生成する「バイブコーディング」が、プログラミングの常識を覆そうとしている。すでにAIが生成するコードの比率が9割を超える企業も現れ、エンジニアの役割は「実装者」から「監督者」へと急速に変わりつつある。この変化は単なる開発手法の進歩なのか。それともIT産業全体を根底から変える大転換の始まりなのか。 by MIT Technology Review Japan2025.08.04 12 キーボードでコードを一行一行書いていくプログラミングから、AIエージェントに自然言語で「ノリ」よく指示を出すだけでソフトウェアを開発する時代へ——。「バイブ（Vibe）コーディング」という

とりあえずコンセプトは動きそうだなぁってくらいで、ちゃんと動くことも確認してないし、テストも書いてないし、まだまだやることはたくさんあるんだけど、どっかでいったんブログに書いて休憩しようと思ったので、書くことにした。年内である程度動くところまで持っていけたらいいな。 Kori Kori (WIP) (英語版を作ってその翻訳をCursorにお願いしたのでそういう感じの日本語になってます) 特徴 TypeScriptの型安全さをわりといっぱい活かしてコードを書ける。 スキーマを定義すると、そのスキーマにしたがってバリデーションが実行されて、その結果を型安全に扱える。その同じスキーマをOpenAPIのスキーマとしても利用できる。スキーマの実装としては、とりあえずZod v4に対応しておいた。 たとえばこんな感じで定義すると const UserSchema = z.object({ name:

2025.08.08 技術記事 OSS の AI レビューツール「PR-Agent」を全社導入し、コスト効率の高い開発支援を実現した話 by tomoya.kawaguchi #ai #code-review #pr-agent #developer-productivity はじめに こんにちは。 SWET の川口です。本稿では、DeNA 全社を対象に AI を活用したコードレビュー支援ツール「PR-Agent」を導入し、実際に運用している事例をご紹介します。 社内での AI ツール導入を検討されている方々や、PR-Agent の運用に興味をお持ちの方々にとって、何らかの参考になることを願っています。 コードレビューの課題と AI による解決への期待 コードレビューは、ソフトウェアの品質向上、バグの早期発見、そして開発チーム内での知識共有を促進する上で不可欠なプロセスです。しかし、Cla

俺（レビュアー）「ここはMath.minを使えば1行で書けるのでそうしてください」 レビュイー「AIがこのように生成しました」 俺「（だから何だよ…と思いつつ）盲目的にAIに従うのではなく、それを受け入れた以上コードの責任はあなたが持ってください」 レビュイー「しかしこの先コードを読むのもAIになってきている以上、AIが生成するコードはAIにとって読みやすい良いコードなんじゃないでしょうか？そもそもですが前から増田先輩は小さいことにこだわってapproveを遅らせすぎです。さっさとリリースしたほうが顧客価値に繋がるのでは？」 30分ぐらい悩んだが反論できず「確かにそういう考えもありますね」って言ってapproveした。 どうするのがよかった？

こんにちは、フロントエンド推進課の水野です。 普段はWebフロントエンド領域を中心に、商材開発や技術支援、開発改善に携わっています。 自動化・標準化、開発プロセスの変遷に関心があり、作るものだけではなくその過程や運用設計を意識して取り組んでいます。 note.com 最近、自分の中でコードレビューのやり方が変わったなと感じています。 GitHub CopilotやClaude Codeのようなツールが当たり前になり、構文エラーやコーディング規約のチェック、命名規則の統一のような作業はほぼ自動化できてしまいます。 成果物の出てくるスピードと規模感も桁違いで、レビューだけで1日が溶ける日もたまにあります。 その中で、改めて「自分は何をレビューすればいいんだろう」「コード以外に見るべきものはなんだろう」と考えることが増えました。 個人的にコードレビューや開発現場に関する話が好きで、ブームが再燃し

「AIが生成したから正しい」——そんな一言が飛び出したコードレビューが、はてな匿名ダイアリーに投稿されました。 レビュアーが「Math.minを使えば1行で書けます」と指摘したのに対し、レビュイーが「AIがこのように生成しました」と返答。さらに、「AIが生成するコードはAIにとって読みやすい良いコードではないか」と主張しましたというお話です。このやり取りはXで多数の議論を産みました。多くが「根拠のないAI盲信」「無責任」と批判。可読性や保守性を重視する声も見られました。 この事例は、AIを「言い訳」に使う危険性を示しています。無意識に楽な選択を正当化するヒトらしい傾向が、プログラマの価値基準を揺さぶっています。 楽な選択に流れるヒトと、プログラマの価値の再定義人は無意識に楽な選択を正当化します。例えば、AI生成コードをレビューなしで本番環境に上げるチームでは、スピードが優先され、コードの可

こんにちは、CTO の田中（@stanaka）です。 最近は趣味で LLM の内部構造を勉強していて、LLM 自作などに手を出しています。 さて、世の中は AI コーディングツールの話題で持ちきりですが、弁護士ドットコムでも活用を進めており、現在の状況をまとめてみました。 導入ツール 弁護士ドットコムでは、以前から GitHub Copilot を使ってきましたが、今年の初頭からさまざまな AI コーディングツールの導入を進めています。 ざっとあげると、GitHub Copilot, Cursor, Cline, Claude Code, Devin あたりのメジャーどころは一通り使えるようにしています。 Kiro もすこしだけ乗り遅れて waitlist 待ちになっていたところ、先日無事に invitation が届きました。 実際の利用状況を聞いてみると Cursor 勢と Claud