RIFFRAFT

Design decisions, layered.

一本の線から、設計は始まる。

コードレビューを、製図行為に変える。

製図を始める — 無料トライアル

鉛筆の先に、
diff が走る。

指摘ではなく、設計を書き込む。コメントではなく、判断を積層させる。

従来のコードレビューは「非同期の指摘合戦」だった。PR を投げ、数時間待ち、コメントの意図を汲み取り、修正し、また待つ。3 往復目には最初の設計意図が霧散している。Riffraft は違う。コードブロックに鉛筆を走らせるように、設計判断をリアルタイムで書き込む。書かれた判断は消えない——コードの一部として、次にそのファイルを開く誰かに設計の文脈を語り続ける。

src/review/engine.rs
42 fn review(ctx: &Context) -> Decision {
43+ let layer = ctx.design_layer();
44+ let intent = layer.trace_origin();
45 match intent.confidence() {
46- Confidence::Low => suggest(ctx),
47+ Confidence::Low => annotate(ctx, layer),
48 Confidence::High => approve(ctx),
49 }
50 }

判断は、積層する。

設計・実装・最適化——3 つの視座を、1 つのコードブロック上に重ねる。

Layer 1 — Architecture
1// Why separate auth into its own service?
2// → Single Responsibility: auth changes
3// shouldn't cascade to billing or notifications.
4pub mod auth_service {
5 use crate::domain::Identity;
この分離は正しい。ただし auth_service が domain 層に依存するのは循環を生む可能性。interface を挟むべき。
Layer 2 — Implementation
1 pub async fn verify(token: &str) -> Result<Identity> {
2 let claims = decode_jwt(token)?;
3 if claims.exp < Utc::now().timestamp() {
4 return Err(AuthError::Expired);
5 }
decode_jwt は既に exp 検証を内包している。二重チェックは除去してよい。テストで担保。
Layer 3 — Performance
1 let identity = db.find_identity(claims.sub).await?;
2 cache.set(&claims.sub, &identity, TTL_5MIN);
3 Ok(identity)
4 }
5}
cache.set のタイミングは DB 読み取り直後で正しい。ただし TTL_5MIN はハードコード。config から取得推奨。
レイヤービューを試す

図面を、広げる。

01

リアルタイム同期エディタ

コードブロック上でチームメンバーのカーソルがリアルタイムに動く。非同期の指摘合戦ではなく、同じ画面を見ながら声とアノテーションで設計を研磨する。レビューセッションは平均 30 分で完了——従来の 3 日待ちが嘘のように消える。

02

設計判断の履歴タイムライン

レビューコメントは消える。しかし Riffraft に書き込まれた設計判断は、コードのバージョン履歴と共に残り続ける。3 ヶ月後のリファクタリングで『なぜこう書いたか』を知りたい時、タイムラインを遡れば設計の文脈が蘇る。

03

AI 要約による次回レビュー高速化

前回のレビューセッションを AI が要約し、次のレビュアーに引き継ぐ。コンテキストの再構築に費やしていた最初の 15 分がゼロになる。レビュアーは初手から設計の核心に切り込める。

04

GitHub / GitLab 双方向同期

既存のワークフローを壊さない。GitHub PR・GitLab MR にリアルタイムレビューのリンクが自動添付される。Riffraft 上のアノテーションは PR コメントとして同期。導入に必要なのはリポジトリ接続のワンクリックだけ。

8 本の鉛筆が、
1 つのコードに集まる。

レビュー待ち 73% 短縮。修正ラリー 62% 削減。バグ流出 61% 減少。

src/review/session.rs
1pub struct ReviewSession {
2 participants: Vec<Reviewer>,
3 code_block: CodeRef,
4 layers: LayerStack,
5}
7impl ReviewSession {
8 pub fn annotate(&mut self, pos: Position, note: &str) {
9 let layer = self.layers.active();
10 layer.add_annotation(Annotation {
11 author: self.current_reviewer(),
12 position: pos,
13 content: note.into(),
14 timestamp: Utc::now(),
15 });
16 self.broadcast_update();
17 }
19 pub fn resolve(&mut self, thread_id: ThreadId) {
20 self.layers.mark_resolved(thread_id);
21 self.sync_to_pr();
22 }
23}
この分岐、テスト漏れてない？
この抽象化、3 ヶ月後に後悔しそう
命名が実装に引きずられてる。ドメイン用語に寄せよう
ここのエラーハンドリング、上位で握り潰されてない？
パフォーマンス: N+1 クエリ。eager load 推奨
LGTM — 設計判断が明確に読める。Approve.

コードレビューの本質は、複数の知性が同じコードに集中することにある。しかし非同期レビューでは、集中のタイミングが揃わない。Riffraft のリアルタイムセッションでは、チームメンバーのカーソルが同時にコード上を走る。声とアノテーションが同時に重なり、数分で設計が研磨される。導入 4 週間で、レビュー起因のデプロイ遅延が平均 2.3 日から 0.6 日に縮まる。

73%
レビュー待ち時間の短縮
0.8回
修正ラリー（従来 2.1 回→0.8 回）
61%
レビュー起因バグの本番流出削減

非同期で 3 日かかっていたレビューが、30 分の同期セッションで完了する。設計意図が残るから、3 ヶ月後のリファクタリングも怖くない。

— 16 名体制の SaaS 開発チーム テックリード
チームで試す — 14 日間無料

鉛筆を、置く。

Put your pencil down.
Let Riffraft draw the lines.

設計図は完成した。ここまでスクロールしたあなたは、コードレビューが「製図行為」であることを体感した。次は、あなたのチームのコードで試す番だ。GitHub リポジトリを接続して、最初のリアルタイムレビューセッションを始めよう。

無料で製図を始める

クレジットカード不要 · 5 分でチーム招待 · GitHub / GitLab ワンクリック連携