プロジェクト概要
このリポジトリでは、実際の採用プロセスから生まれたAIコーディングプロジェクトの課題3題を整理し、時間制限付きの筆記課題、Take-home Assignment、対面でのペアプログラミングに応用できる汎用的な方法をまとめています。課題文は匿名化および構造化して書き換えてあり、企業名、面接官、採用担当者、顧客名は含まれていません。
このリポジトリに主に収録されているのは課題の振り返りと方法論です。対応する3つの個人実装は独立したリポジトリにあり、ソースコード、設計ドキュメント、テスト、実際の納品記録が含まれています。
これらのプロジェクトで本当に評価されるのは、コード量だけではありません。要件理解、アーキテクチャの境界、プロセス管理、受け入れの証拠、そしてトレードオフを判断する力です。
3つのプロジェクトで評価されるポイント
01：Computer Use Agent Dashboard
1つ目の課題では、Web、Agent、分離されたデスクトップを組み合わせたシステムの構築を求められます。Computer Use、ツール呼び出しループ、セッション分離、可観測性、ランタイムの信頼性が主な評価対象です。
- 課題の振り返り：Computer Use Agent Dashboard
- 個人実装：ai-agent-dashboard
この種のプロジェクトでは、モデルAPIの呼び出しと画面表示を実装するだけでは不十分です。Agentがどのようにツールを呼び出すのか、各セッションをどのように分離するのか、また失敗状態を観測して復旧できるのかにも注目する必要があります。
02：React Native スクリーンショットアクションAgent
2つ目は、48時間で完成させるReact Native／iOSプロジェクトです。スクリーンショットを入力として、多モーダル理解、構造化Action、Human-in-the-loop、ネイティブツール、Memoryが主な評価対象となります。
- 課題の振り返り：React Native スクリーンショットアクションAgent
- 個人実装：ContactFlow
この種の課題の要点は、スクリーンショットを理解し、構造化されたアクションを生成し、ユーザーに確認してもらい、適切なネイティブ機能で実行するという完全なループを作ることです。自然言語の提案を出力するだけでは不十分です。
03：Jira風タスク管理システム
3つ目の課題では、1日でWeb MVPを完成させます。主な評価対象は、要件の取捨選択、CRUD、カンバンのドラッグ＆ドロップ、ローカル永続化、タイムライン、そして全体的な納品品質です。
- 課題の振り返り：Jira風タスク管理システム
- 個人実装：ForceTrack
このプロジェクトには、PRDからRepo Wikiに至る24回の実際のAIコーディング対話も収録されています。要件、実装、ドキュメントがどのように段階的に進められたかを確認できます。
中核メソッド：AIコーディングプロジェクトを完成させる6ステップ
AIコーディングプロジェクトの汎用的な進め方では、全体の流れを6つの段階に分けています。課題がAgent、モバイルアプリ、CRUDシステムのいずれであっても、この順序で進められます。
第1ステップ：要件を明確にし、スコープを凍結する
まず、曖昧な説明を検証可能なP0スコープに変換します。必ず実装するもの、後回しにできるもの、明確に実装しないものを区別し、時間制限付きプロジェクトで要件が拡大し続けるのを防ぎます。
まずは簡単な要件マトリクスを作成します。
要件：ユーザーは何を操作できるか？
受け入れ条件：操作が成功したことをどう証明するか？
優先度：P0に該当するか？
状態：未着手、進行中、検証済みのどれか？
リスク：依存関係、権限、失敗経路、時間コストは何か？マトリクスで重要なのは形式ではなく、すべての作業を明確な受け入れの証拠に結び付けることです。
第2ステップ：Starterまたは既存リポジトリを監査する
面接側からStarterが提供されても、すぐに書き直してはいけません。まず既存のディレクトリ、依存関係、ビルド方法、データモデル、再利用可能なコンポーネントを確認し、そのうえで何を残し、拡張し、置き換えるかを判断します。
- プロジェクトを正常にインストール、ビルド、実行できるか確認する。
- 既存の状態管理、永続化、テスト方法を把握する。
- プラットフォーム、権限、ランタイムの制約を確認する。
- ブロッカーを記録し、AIが誤った前提でコード生成を続けないようにする。
第3ステップ：データ、状態、ツール、ランタイムを設計する
課題によって重視される境界は異なります。Agentプロジェクトではツールループ、セッション分離、失敗からの復旧を考える必要があります。モバイルプロジェクトでは構造化Action、ユーザー確認、ネイティブツールが重要です。タスクシステムではCRUD、ドラッグ＆ドロップの状態、ローカル永続化、タイムラインに注目します。
設計時には、正常状態、ローディング状態、失敗状態、復旧方法を明確にします。メインフローだけで境界条件を考慮していない実装では、通常、納品可能な完全なループにはなりません。
第4ステップ：垂直スライスでAIタスクを分割する
AIにシステム全体を一度に生成させないでください。より安定した方法は、各スライスに必要なデータ、ロジック、画面、検証を含め、垂直スライス単位で進めることです。
AIに渡すタスクの契約には、少なくとも次の内容を明記します。
目標：今回の作業で完成させる、目に見える結果
範囲：変更してよいモジュール
制約：技術スタック、時間、互換性の要件
受け入れ条件：必ず通過すべき操作またはチェック
禁止事項：今回拡張してはいけない機能この分割方法により、コンテキストのずれを減らし、各ラウンドで人がレビューしやすくなります。
第5ステップ：人によるレビューと自動検証
AIは実装速度を高められますが、技術的な判断は引き続き開発者の責任です。変更のたびに、要件に沿っているか、既存の動作を壊していないか、失敗経路が処理されているかを確認します。
- 既存のテストとビルドプロセスを実行する。
- 主要なユーザーフローを手動で検証する。
- 状態、権限、永続化、境界条件を確認する。
- 画面表示と実際の実行結果が一致しているか確認する。
- 「コードを生成した」と記録するだけでなく、受け入れ結果を記録する。
第6ステップ：時間制限下で取捨選択し、デモと最終納品を行う
時間が足りない場合は、価値の低いスコープを積極的に削り、P0の完全なループを優先します。最終納品にはソースコードだけでなく、ビルド結果、テスト、デモ、ドキュメントを用いて、プロジェクトが実際に動作することを証明する必要があります。
簡単な納品チェックリストは次のようにまとめられます。
主要フローは完成しているか？
プロジェクトをビルドして起動できるか？
重要な失敗経路を処理できているか？
データまたは状態を要件どおり保存できているか？
デモ手順は安定して再現できるか？
ドキュメントにスコープ、取捨選択、既知の制限が記載されているか？このリポジトリの使い始め方
これは課題の振り返りと方法論をまとめたリポジトリであり、依存関係を一括インストールして起動するアプリケーションではありません。そのため、準備作業の中心は資料を読み、テンプレートをコピーし、具体的な課題に合わせて自分の実行計画を立てることです。
- GitHubページでこのリポジトリをクローンまたはダウンロードする。
- 3つのプロジェクト課題を順番に読み、異なる形態におけるエンジニアリング目標と受け入れの重点を理解する。
- 汎用的な進め方を読み、要件マトリクス、タスク契約、納品チェックリストをコピーする。
- 課題を1つ選び、時間内に完成できるP0スコープに要件を絞る。
- 実装の詳細を調べる必要があれば、対応する個人実装リポジトリでソースコード、設計ドキュメント、テストを確認する。
READMEで推奨されている順序はまず3つの課題を読み、その後に汎用的な進め方を読むことです。実際に取り組む際は、すべてのテンプレートをそのまま使う必要はなく、プロジェクトの規模と期限に応じて削減してください。
基本的な実践例
Jira風タスク管理システムを練習するとします。まずは1日で検証可能な中核ループに目標を絞り、CRUD、カンバンのドラッグ＆ドロップ、ローカル永続化、タイムラインを中心に実装と受け入れを計画します。各部分を完成させるたびに状態更新と永続化の結果も同時に検証し、すべての画面が完成してからまとめてテストすることは避けます。
スクリーンショットアクションAgentを練習する場合は、「スクリーンショット入力、多モーダル理解、構造化Action、ユーザー確認、ネイティブツール」を中心に垂直スライスを構成します。各段階で人による確認と検証の手順を残し、モデルの出力をそのまま信頼できる実行結果とみなさないようにします。
Computer Use Agent Dashboardでは、ツールループ、セッション分離、可観測性、ランタイムの信頼性を優先的に検証します。画面はシステムの一部にすぎず、実行過程を追跡できるか、失敗後にどう処理するかも受け入れ範囲に含まれます。
応用テクニック
機能数よりも受け入れの証拠を優先する
時間制限付きのプロジェクトでは、テストとデモを済ませた3つの完全な機能のほうが、安定して動作しない10個の画面より説得力があります。すべてのP0機能について、操作、テスト、ビルド結果、またはドキュメントで証明できるようにします。
AIには実装を加速させ、意思決定は任せない
AIは境界が明確なタスクに適していますが、スコープの分割、アーキテクチャの取捨選択、リスク判断、最終レビューは開発者が管理する必要があります。タスクが曖昧であるほど、大量のコードを一度に生成した際の手戻りリスクは高くなります。
状態と復旧経路を優先的に確認する
3つの課題は形態こそ異なりますが、いずれも状態、失敗、復旧、権限、永続化、または境界条件に関係します。デモの前には、異常な入力、ツールの失敗、状態の切り替え、アプリに再び入った後の動作を意識的にテストします。
実際の対話履歴で協業方法を振り返る
ForceTrackの24回の実際の対話は、AIコーディングのプロセス管理を分析するのに適しています。読む際は、各ラウンドの目標がどのように収束したか、タスクがどのように分割されたか、そして結果がPRDからRepo Wikiへどのように段階的に蓄積されたかに注目してください。
まとめ
この資料の価値は、3つの練習課題を提供することだけではありません。まず要件を理解してスコープを凍結し、環境を監査し、境界を設計し、タスクを分割して人がレビューし、最後にテスト、ビルド、デモ、ドキュメントで受け入れを完了するという、再利用可能なAIコーディングの納品方法を示しています。
実際の採用プロセスでは、課題文、期限、機密保持要件が異なる場合があります。これらの方法を使う際は、必ず受け取った正式な資料を基準とし、時間に応じて価値の低いスコープを積極的に削減してください。