バイブコーディングでPRを作成したあとの修正・再チェック・マージを自動化してくれるツール autoland を紹介します。 プルリクエストについたレビューコメントをcodexやclaude codeに転送して修正依頼を出し、修正が完了したらマージを実行するところまでを自動化します。作業内容のサマリーはPRのコメントとして残ります。 機能概要Open状態のPRを自動で見つけて処理開始 GitHub checksが終わるまで待ち、完了後にAIに対応を依頼 マージに問題がないか判定し、可能ならそのままマージ マージ不可なら修正してgit push → 再チェック 作業内容のレポートをコメントとして投稿 隣接する機能のバグや以前から失敗したままのテスト等、作業中のPRの範囲を超える問題を検知したらIssueを作成（オプション） 単発実行とWatchモードの2形態 概要autolandは、プルリクエ

記事をお読みいただきありがとうございます。 モブエンジニア（Masaki Okuda）です。 横浜北部LT会が始まったということもあり仕事終わりに爆速で行って参加しました！！ 便利ツールは自分で作る！ 〜AI開発ツールを運用している話〜山本さんからAI開発ツールを運用している話でした！！ 私も前職で簡単な学習ツールを開発して新卒にばらまくことを行っていたので、AI開発ツール運用話は興味があります。 Mac向けスクショツール（HTMLファイルのみ）を作成されたのはすごくいいですね！！私もサクッと実装してみようと思います！！ Claude Code を使いこなす試行プロセスと思考プロセスしゅういちろうさんからClaude Codeを使いこなす試行プロセスに関する話でした！！LT内でリアルタイムアンケートを行うアイデアはすごく面白いですね！！ Claude Codeの思考プロセスは残しておいた方

「スローai」のススメ:開発者が速度偏重をやめるべき理由The rise of Slow AI: Why devs should stop speedrunning stupidの意訳です。 私たちがコンピューターを使い始めて以来、そこには常に1つの基本ルールが存在しました。それは、速ければ速いほど良いということです。低レイテンシ、高スループット、待ち時間の短縮、これが鉄則でした。ボタンの応答に600ミリ秒もかかったり、注意力が維持できなくなるほど長いスピナーを見たりすることを望む人はいません。遅いということは、それは壊れているということです。議論の... 統一的プロンプトの終焉：もはやllmモデルに互換性はありませんWhy LLM models are no longer interchangeableの意訳です。 開発者やプロダクトビルダーにとって、この数年間はLLMがアプリケーション

統一的プロンプトの終焉：もはやllmモデルに互換性はありませんWhy LLM models are no longer interchangeableの意訳です。 開発者やプロダクトビルダーにとって、この数年間はLLMがアプリケーション開発を導いてきました。プロダクトを改善したいなら、最新のLLMを利用すれば良い。ただモデルを切り替えるだけで、ツールの性能を一段階引き上げられるのです。 しかし、その時代は終わりました。AnthropicのClaude Sonnet 4.5やOpenAIのGPT-5-Codexのような新しいモデルは、根本的に異なる方向へ分岐... 先日6,000万ドルを調達したので…おもしろ動画を作りましたWe raised $60M last week… so we made a funny filmの意訳です。 先日、CodeRabbitはシリーズBで6,000万ドルの

こんにちは、ナレッジワークのソフトウェアエンジニアの石川宗寿 (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