Kaptiメソッド
スケッチからコードへ：私たちが実際に使っているツールとその理由
「何を使って仕事をしているのですか？」とよく聞かれます。正直な答えは、「私たちが去った後もクライアントのチームが保守できるもの」です。ただ、案件を重ねる中で繰り返し使うツールもあります。モックアップと納品されるプロダクトの距離を縮めてくれるからです。どのツールを使っているのか、工程ごとにご紹介します。
ツールが良いプロダクトをつくるわけではありません。しかし、ツールのつなぎ方が悪いと、多くのプロダクトが損なわれます。コードで描き直すことになるモックアップ、3つの名前で3回存在するコンポーネント、再現できないAIデモ。私たちの選択はすべて、同じ考えに基づいています。 デザイン、コード、AIが同じ言葉で語ること。最初のインタビューから本番リリースまで一貫しています。
理解する：画面の前にリサーチ
案件で最初に使うツールは、最もシンプルなものです。インタビューガイド、録音機、共有の表。ユーザーや業務チームにインタビューし、可能なときは現場で観察し、学んだことを誰でも読み返せるまとめに整理します。
ここではAIが時間を節約してくれますが、明確な線引きがあります。AIは書き起こしやグループ分けを手伝いますが、何が重要かを決めるのはAIではありません。まとめに載る引用はすべて、インタビューを行った本人が確認しています。
設計する：Figmaと、文書化された判断
私たちは Figmaで設計します。多くのプロダクトチームが使っているツールであり、スクリーンショットをやり取りする代わりに、クライアントと画面上で直接コメントし合えるからです。ツールそのもの以上に重要な習慣が3つあります。
- 最初の画面からコンポーネント化する。 2週間のモックアップでも、ボタンや入力欄はすべてコンポーネントにします。そうすることで、すべてを描き直さずにコードへ移行できます。
- デザイントークン。 色、書体、余白、角丸は一度だけ名前を付け（「セカンダリテキスト」「サーフェス」「アクセント」）、あらゆる場所で再利用します。たとえば本サイトのダークモードは、同じ名前に対する2つ目の値のセットにすぎません。
- 見落とされがちな状態。 読み込み中、エラー、空のリスト、AIの不確かな回答。主要な画面は理想的なケースだけでなく、こうした状態でもデザインします。
テストする：本当に動くプロトタイプ
AI機能の場合、静的なモックアップは実態を正しく伝えません。毎回完璧な回答を見せてしまうからです。そこで私たちは、実際のモデルとリアルなデータにつないだ 動作するプロトタイプで検証し、5〜7人のユーザーに実際に操作してもらいます。私たちの 社内プロジェクトのデモ のデモも、すべてこの方法で作られています。ブラウザ上で動くコードと、デモ用データです。
開発する：React、ドキュメント化されたコンポーネント、必要に応じてWebflow
プロダクト開発では主に React を使用しています（モバイルはReact Native）。クライアントの既存基盤がAngularの場合はAngularで開発することもあります。サーバー側は状況に合わせて選びます。確立された情報システムではJava、新しいプロダクトではNodeとPostgreSQL。ハッカソンから生まれた拡張機能Swingも後者の例です。
デザインとコードをつなぐのは Storybook です。各コンポーネントのバリエーション、状態、アクセシビリティのルールをここにドキュメント化します。デザイナーと開発者が同じカタログを参照でき、私たちが離れた後も、クライアントのチームはどこを見ればよいか分かります。
マーケティングチームが自分たちで運用するコーポレートサイトには、 Webflow を選びます。Moofizeに納品したのもこの形で、同社のチームは開発者なしでページを更新しています。
AIを組み込む：課題に合ったモデルを
モデルは習慣で選びません。目的に応じて使い分けます。
- 言語モデル ：要約、分類、下書きの作成に。
- 社内文書の検索（RAG） ：回答を御社の情報源から引き出し、出典を示す必要がある場合に。商品情報、契約書、社内ドキュメントなど。
- 画像認識モデル ：写真の確認や、スキャンした書類の読み取りに。
最終的な選択は、要件定義の段階で確認する3つの制約で決まります。データをどこに置いてよいか（ホスティング、機密性）、規模を拡大したときの呼び出し1回あたりのコスト、そしてモデルが間違えたときに何が起きるか。3つ目は、技術の問題であると同時にデザインの問題でもあります。
私たちの情報収集。 モデル、ツール、規制は四半期ごとに変わります。私たちは社内プロジェクトで継続的にテストし、得られた知見をこのブログで共有しています。たとえば EU AI法（AI Act）第50条の読み解き.
検証する：手作業でのアクセシビリティテスト
自動ツールで検出できるアクセシビリティの問題は一部に限られます。そのため、キーボード操作、スクリーンリーダー（VoiceOver、TalkBack、NVDA）、200%ズームでのテストで補い、クライアントがアクセシビリティ宣言を公開する必要がある場合は、RGAAのチェックリストで確認します。
引き継ぐ：案件の後に残るもの
技術スタックの真価が問われるのは、クライアントのチームが引き継ぐ日です。そのため、整理されたFigmaファイル、デザインとコードで共有するトークン、最新のStorybook、そして判断の理由を説明する簡潔なドキュメントを残します。画面を1つ追加するのに私たちを呼び戻す必要がなければ、ミッションは成功です。
よくある質問
ツールを指定されますか？
いいえ。御社のチームが保守できるものを前提にします。Angularや他のプラットフォームをお使いなら、その環境で作業します。
どのAIモデルを使っていますか？
ユースケースと、機密性・コスト・ホスティングの制約に合ったモデルです。選定理由は要件定義の段階で文書にしてお伝えします。
デザインシステムはコードでも納品されますか？
はい、ミッションに含まれている場合は。Storybookでドキュメント化したReactコンポーネントを、Figmaライブラリと同じトークンで納品します。