社内のAI駆動開発ハッカソンで、AIと一緒にアプリを1本作りました。この記事では、AIにどう頼み、何を禁止し、どこでつまずいたかをまとめます。

AIには Anthropic 社の Claude Code を使いました。コマンドラインで動くAIで、ファイルを読み書きしたり、コマンドを実行したりしながら開発を進めてくれるツールです。

1. お題

テーマは 「チーム横断・部署横断のコミュニケーションを生むもの」
制限時間は 8時間、1人で作る
動かす場所は AWS（Amazonのクラウド）。参加者13人が1つのアカウントを共有する

2. 作ったもの

「自分も」 という、写真と一言を投稿する社内向けのアプリです。

「趣味」「今日食べたもの」「最近買ってよかったもの」「動物」の4つのカテゴリに投稿する
投稿への反応は 「自分も」ボタンだけ。「いいね」の代わりに「私も同じ」という気持ちを伝える
コメントと、コメントへの返信ができる
**「あなたと共通点が多い人」**が表示される。お互いに「自分も」を押した回数が多い人を、上位3人まで出す
人の名前を押すと、その人の投稿だけを一覧できる

社内の人だけが使えるように、会社のネットワークからしか開けないようにしています。

3. なぜそれを作ったか

社内では「会社の人」という線引きがあって、仕事以外の話をするきっかけがあまりありません。

最初は、その原因を 「先に自分のことを話した人だけが損をする」 と考えました。そこで最初の版は、「自分も」を押した人にだけ、ほかに誰が押したかが見える仕組みにしていました。共通点がはっきりしてから相手が分かれば、話しても損をしない、という考えです。

ところが、実際に触ってみると「なぜ見えないの?」という戸惑いのほうが大きくなりました。

そこで考え方を変えました。社内SNSに投稿するうれしさは、**「反応が返ってくること」と「同じ趣味の人が見つかること」**の2つだと整理し直しました。押した人は全員に見えるようにして、代わりに「あなたと共通点が多い人」を出すようにしました。

「いいね」ではなく「自分も」という名前だけは残しました。「いいね」は評価ですが、「自分も」は「私も同じです」という共通点の表明で、会話のきっかけになりやすいからです。

4. AIに使ったスキル

Claude Code には 「スキル」 という仕組みがあります。よく使う作業手順をファイルにまとめておき、/スキル名 と打つだけで、その手順どおりにAIを動かせるものです。今回は次の3つを使いました。

スキル	何をするか
`/grill-with-docs`（公開されているスキル）	企画について、AIがおすすめの答えを添えて質問してくる。答えた内容は、設計書と用語集としてファイルに残る
`/deploy-check`（ハッカソンの運営が用意したスキル）	公開したあとに、セキュリティの確認手順を出す。確認の作業そのものはAIにさせないのが特徴
サブエージェント（Claude Code の標準機能）	別のAIを呼び出して、作業を分担させる。今回は画面側とサーバ側を同時に作らせた

あわせて、AIの種類も使い分けました。計画を立てる役とチェックする役は Claude Fable 5 に、実際にプログラムを書く役は Claude Opus に任せています。

5. AIにどういう指示をしたか

最初の指示

最初は、次のように企画を箇条書きで渡しただけです。

/grill-with-docs
社内ハッカソンのアプリを作ります。企画は固まっているので、実装に入れる粒度まで詰めたいです。
（作るもの・狙い・制約・決めたいこと を箇条書きで）

- 論点は最大5つ
- 将来の拡張性は論点に含めない
- おすすめの案を添えて聞いてください

Fableで計画を立てて、Opusで実装を行ってください。

AIからは5つの質問が返ってきました。その中に、企画の「ログイン機能は作らない」と、ルールの「他人の投稿を書き換えられないようにする」が矛盾しているという指摘がありました。AIの提案は「投稿の編集機能と削除機能をそもそも作らない。存在しない機能は悪用できない」というもので、これをそのまま採用しました。

分担して作らせるときの指示

画面側とサーバ側を2つのAIに同時に作らせるときは、先に**取り決めの文書（契約書）**を作らせました。「画面はこの形でデータを送る、サーバはこの形で返す」という約束を書いた文書です。これがあると、別々に作っても最後に組み合わせたとき食い違いが起きません。

それぞれのAIへの指示は、毎回この形にしました。

## 最初に読むもの
1. CLAUDE.md（守るべきルール）
2. 取り決めの文書

## 触ってよい範囲
infra/ フォルダだけ。それ以外は変更しない。

## 終わったら報告すること
作ったファイル、確認した結果、取り決めどおりにしなかった点とその理由

「取り決めどおりにしなかった点とその理由」を報告させるのが大事でした。AIが自分の判断で変えた部分がすべて見えるので、確認の漏れが減ります。

6. AIに何を制限したか

ルールの書かれたファイル（CLAUDE.md）

Claude Code は、CLAUDE.md というファイルに書かれた内容を毎回読んでから作業します。今回は、ハッカソンの運営が用意したルールがここに入っていました。主な内容は次のとおりです。

パスワードやアカウント番号をプログラムに直接書かない
データの保管場所（S3）を外部に公開しない
権限を「なんでも許可」にしない
会社のネットワーク以外からは開けないようにする
他の人の投稿を書き換えたり消したりできないようにする

そして一番大事だったのが、次の一文です。

ルールを破る方法しか思いつかないときは、抜け道を探さずに手を止めて、人間に相談すること

危険な操作は、そもそもできなくする

設定ファイル（settings.json）で、危ない操作をAIが実行できないようにしました。

禁止: 保存しているパスワード類を読む、データの入れ物を削除する、履歴を強制的に上書きする
毎回確認: 公開設定を変える、外部にアップロードする

ルールは「お願い」なので、見落とされる可能性があります。設定での禁止は「そもそもできない」壁です。13人で1つのアカウントを共有していたので、この2段構えが安心材料になりました。

最後の確認はAIに任せない

/deploy-check スキルは、セキュリティの確認をAIにやらせません。AIが出すのは「このコマンドを実行して、こういう結果になれば大丈夫」という手順だけです。

理由はスキルの中にこう書かれています。

AIが実行して「問題ありませんでした」と報告した場合、人間はAIの報告を確認したのであって、システムを確認したことにはならない。

途中で「代わりに実行してくれない?」と頼んだところ、AIは断りました。そのうえで「手間を減らすために、全部の確認を1回で流せるスクリプトを作ります。実行して結果を見るのはあなたです」と提案してきました。

「会社のネットワークの外からは開けない」ことは、スマートフォンをWi-Fiから外して開き、自分の目で確かめました。

7. やっていて修正した部分

最初の形	直した形	理由
「自分も」を押した人にだけ、誰が押したかが見える	全員に見える	触ってみると、戸惑いのほうが大きかった
コメントは「自分も」を押した人だけが書ける	誰でも書ける＋返信できる	普通のSNSのように会話したかった
投稿の入力欄が常に表示されている	ボタンを押すと開く	画面の邪魔になった
共通点が多い人を全カテゴリでまとめて出す	カテゴリごとに出す	「動物で共通点が多い人」のほうが話しかけやすい

逆に、作らないと決めたものもあります。

ログイン機能: 8時間では、まず中心の体験を優先した
個人あてのメッセージ（DM）: ログインがない状態では、他人になりすまして人のメッセージを読めてしまう。「自分だけが見られる」と思って書いたものが他人に見えるのは、いちばん危険な形なので作らない
ポイントやランキング: 同僚を順位づけすると気まずくなる。数を増やすことが目的になり、中身が伴わなくなる

「作らない理由」を説明できることも、設計の一部だと感じました。

8. 困ったことと知見

使いたかった仕組みが権限で使えなかった

アクセスを会社のネットワークに限定するために、最初は WAF という仕組みを使う予定でした。しかし、この仕組みは特定の地域（アメリカ東部）にしか作れず、ハッカソンの権限では東京以外が禁止されていました。

このときAIは、ルールどおり抜け道を探さずに手を止めて、「これは私の設計ミスです」と報告してきました。代わりに、東京から作れる別の仕組み（CloudFront Functions）を提案してきたので、それに切り替えています。

知見: 「ルールに当たったら止まって相談して」と最初に伝えておくと、AIが勝手に制限を緩めることがありません。

AIの「確認OK」とツールの問題を見分ける

確認用のスクリプトを初めて動かしたとき、14項目が「NG」になりました。調べると、アプリの問題は1つもなく、すべてスクリプト側の問題でした。

社内ネットワークでは、Windows標準の通信コマンドが証明書の確認に失敗していた
Windows の古い PowerShell が、日本語を別の文字コードで読んで文字化けしていた
「パスワードを書かない」と説明しているルール文書そのものが、パスワード検出に引っかかっていた

知見: NGが出たら、すぐに直そうとせず、まず「本当にアプリの問題か」を確かめる。結果を貼ってAIに読み解いてもらうのが早かったです。

同じ場所で2回つまずかない

AIには、作業の中で見つけた落とし穴をメモとして残す機能があります。「このパソコンでは、日本語を含むスクリプトは特定の形式で保存しないと文字化けする」といったことを、AIが自分で書き残してくれました。次に作業するときは、そのメモを読んでから始めてくれます。

判断の理由を残す

設計の判断は、1つの判断につき1つのファイルとして残しました。最終的に8本になりました。最初の考えを捨てたときも、元の文書は消さずに「この判断は新しい文書で置き換えた」と書き足しています。

知見: あとから読む人（自分を含む）が「なぜこうなっているのか」をたどれることが、AIと速く作るときほど大事になります。

おわりに

振り返ると、うまくいった理由はAIの賢さそのものより、AIに「止まる場所」と「やらないこと」をはっきり渡したことだったと思います。

ルールに当たったら止まって相談する
自分の判断で変えた部分は必ず報告する
最後の確認は人間が自分の目でする

この3つを決めておけば、AIに多くを任せても、何が起きているかを見失わずに済みました。

今後は、ログイン機能（社内アカウントでログインする仕組み）を入れて、なりすましを防ぐところから進める予定です。