1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

8時間ソロハッカソンでClaude Codeとどう向き合ったか

1
Posted at

はじめに

 先日、社内で開催されたAI駆動開発ハッカソンに参加しました。
 制限時間は8時間、評価軸は「AI活用の質」「成果物」「セキュリティ」「コード理解度」「運用・ドキュメント」「ナレッジシェア」の6項目で、中でも「AI活用の質」が最も重く評価されるルールでした。

 この記事では、作った物そのものよりも「Claude Codeとどう協業したか」にフォーカスして振り返ります。

ハッカソンのルールと制約

  • 参加形式:1~4人のチーム制(今回は一人で参加しました) / 8時間の短期集中枠
  • 評価軸:AI活用の質(最重視)、成果物、セキュリティ、コード理解度、運用・ドキュメント、ナレッジシェア
  • 開発環境の縛りは特になし、AIツールの活用は前提かつ推奨

 8時間という制約の中で「動くものを作る」ことと「AIとの協業プロセスを説明できる状態にする」ことを同時に達成する必要があり、最初にここの時間配分をどう考えるかが勝負どころだと感じました。

テーマ選定 — ボツ案も含めて

 最終的に選んだのは、[部署をまたいだ質問・回答・お知らせ掲示板]というテーマでした。
 実はここに至るまでにいくつか案を検討し、ボツにしたものもあります。

 そのうちの一つは社内チャットのメッセージを収集・要約する仕組みでしたが、自由記述のテキストや機密情報が混入するリスクを設計段階で排除しきれないと判断し、早い段階で見送りました。8時間という短時間の中では「安全に倒せる設計かどうか」を先に見極めることが、後工程の手戻りを防ぐ意味でも重要だと感じています。

 最終的に選んだテーマは、扱うデータが質問文・回答文・タグといった、業務上センシティブになりにくい情報に絞られる点、CRUDや検索、リアクションなど機能の幅を出しやすく「成果物」の評価軸でも見せ場を作りやすい点が決め手でした。

Claude Codeとの役割分担

 8時間という制約の中で、すべてをClaude Codeに任せるのではなく、次のような役割分担を意識しました。

  • 自分が決めること:テーマ選定、機能の優先順位付け、アーキテクチャの大枠(サーバーレス構成にするかどうかなど)、セキュリティ上の許容範囲
  • Claude Codeに任せること:個々の機能の実装、定型的なコードの生成、バグの切り分けと修正案の提示、ドキュメントの下書き

 特に効果的だったのは、CLAUDE.md にプロジェクトのルールや評価軸を明記しておいたことです。これにより、以降のやり取りで「このハッカソンではセキュリティ面もちゃんと見られる」といった前提を毎回説明し直す必要がなくなり、指示のコストが大きく下がりました。

印象的だった軌道修正の場面

 実装を進める中で、一見ロジックのバグに見えて実は別の原因だった、という場面がいくつかありました。

 代表的だったのが、SPA向けのルーティング設定がAPIのレスポンスまで意図せず横取りしてしまう問題です。フロントエンドのルーティングを成立させるための設定が、本来素通りさせるべきAPIのエラーレスポンスにまで作用してしまい、原因の切り分けに時間がかかりました。最終的には、影響範囲をAPIパス以外に限定する形で設定を見直すことで解決しましたが、この手の「設定の意図しない副作用」は、AIに闇雲に修正を依頼するよりも、まず人間側で影響範囲の仮説を立ててから相談する方が早く収束すると感じた場面でした。

プロンプトの工夫・うまくいかなかった指示

 うまくいったプロンプトの傾向として、次のようなものがありました。

  • 「この機能を実装して」ではなく、「この機能を実装する上でのトレードオフを2〜3案出してから、おすすめを教えて」という聞き方をすると、後から手戻りしにくい実装になりやすい
  • バグ調査を依頼する際は、事象だけでなく「いつから発生しているか」「直前に何を変更したか」もセットで伝えると、原因切り分けの精度が上がる

 逆にうまくいかなかったのは、複数の機能追加を一度に依頼したケースです。優先順位を明示しないまま並列で指示を出すと、重要度の低い部分に時間が割かれてしまうことがあり、残り時間が少ない場面ほど「今やるべきはどれか」を先に自分の中で決めてから依頼する必要があると学びました。

NOTES.mdを書きながら開発したことの効果

 実装と並行して、決定事項・詰まったポイント・試したプロンプトを NOTES.md にリアルタイムで書き残していました。これは主に「運用・ドキュメント」「ナレッジシェア」の評価軸を意識した取り組みでしたが、副次的な効果として、ハッカソン終了後の振り返りやこの記事の執筆自体がかなり楽になりました。

 「後で書こう」と思うと、ほぼ確実に細部を忘れるので、詰まった瞬間・意思決定した瞬間にその場で書く、という運用が短時間開発では特に有効だと感じました。

残タスクと今後

 8時間の中では実装しきれず、今後の課題として残した項目もあります。

  • 回答への1段階の返信スレッド機能
  • 類似質問検索ロジックの高度化(現状は簡易ロジックで実装し、将来的な差し替えを見据えて関数を切り出し済み)
  • ランキング表示部分のレイアウト微調整
  • その他UXの細かい改善

 これらについては、まとまった開発時間を確保できたタイミングで着手し、進捗があれば社内ブログ等で共有していきたいと考えています。

まとめ

 ハッカソンという時間制約のある環境では、AIに「何を」「どこまで」任せるか、の線引きを事前に決めておくことが、成果物のクオリティとAI活用の質の両方を上げる鍵になると感じました。
 特に、意思決定のログをリアルタイムで残す習慣は、開発中の思考整理だけでなく、事後のドキュメント化・ナレッジシェアにも直結する投資対効果の高い取り組みでした。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?