0
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?

個人開発でコーディングAIに振り回されないために、自分用テンプレートを作った話

0
Last updated at Posted at 2026-06-21

はじめに

2026年上半期、自分の個人開発の進め方は大きく変わりました。
きっかけは、自分用の開発テンプレート(Amplify Gen 2 x Kiro)を作ったことです。

ただ、この記事で伝えたいのは「Amplify x Kiro が最高だった」という話だけではなくて、

コーディングAIに頼るほど、こちら側に拠り所となる"型"が必要になる

ということです。

自分は本職のプログラマではないです。
簡単な業務効率化の一環でちょっとしたコーディングをすることはありますが、日常的にコードを書いてプロダクト開発をしているわけではありません。そのため個人開発では以前からコーディングAIにかなり頼っていました。

この記事では、2026年上半期のAI活用を振り返りながら、自分用テンプレートを作ってよかったことをまとめてみます。

以前からコーディングAIにはかなり頼っていた

ツールとしては、Cursorを使ったり、VSCodeの拡張でClaude Codeを使ったりしていました。MCPサーバーの設定だけはして、あとは対話の内容だけで頑張る、というスタイルです。

AGENTS.mdやCLAUDE.mdのようなルールファイルは存在は知っていたものの、正直あまり使いこなせていなかったです。

専業のプログラマではない自分にとって、コーディングAIはかなり強力な支援ツールです。
実際、AIがなければ個人でWebアプリを作るハードルはもっと高かったと思います。

ただ、しばらく使っているうちに、ある課題を感じるようになりました。
それは、AIに頼っていると、毎回構成が安定しない ということです。

【課題】AIに相談するたびに構成がブレる

コーディングAIは便利ですが、前提となる情報が不足していると、毎回提案される構成が微妙に異なってきます。誰しも通る道だとは思いつつ、ご多分に漏れず自分も直面した課題でした。

特にバグやエラーが発生してなかなか解決できなかったときが要注意です。
こちらもAIの返答への注意が散漫になってきたタイミングで、Allowを連発したときに発生します。
「あ、そこ変えちゃうんだ・・・」となるようなその場しのぎの修正が入ることもありました。

私自身、本職のプログラマではないため、AIの提案が妥当なのかを毎回判断するのは簡単ではないです。

AIが自信満々に提案してくれると、「たぶんこれで良いのだろう」と思って進めてしまいます。
この蓄積で、最終的な構成が安定しないという結果になってしまっていました。

必要だったのは、AIに頼るための"型"だった

この経験から感じたのは、コーディングAIをうまく使うには、ただ質問するだけでは足りないということ。

必要だったのは、AIに頼るための"型" でした。

AIは、前提条件がない状態でも回答してくれます。
ただその場合は「その場でそれっぽい最適解」が返ってきます。

一方で、自分が欲しかったのは、毎回違う最適解ではなく、自分にとって扱いやすく、毎回同じ土台で安定して作れる構成 でした。

つまり、個人開発において重要だったのは、

「AIに何を聞くか」だけではなく、「AIに何を前提として渡すか」

でした。

そこで、自分用の標準構成として開発テンプレートを作ることにしました。

自分用テンプレートを作った

今回作ったテンプレートの目的は、単なるコードの雛形を用意することではないです。

目的は、コーディングAIに頼るときの前提を固定すること でした。

具体的にやったのは2つです。

  1. Kiroの仕様駆動開発を取り入れて、アプリ開発の進め方を安定化
  2. Amplify Gen 2構成に固定して、AWS構成の安定化

そして重要なのが、テンプレート自体にKiroのSteering(常駐ルール)を仕込んでいること。

Steeringにプロジェクトの方針や技術スタックを書いておけば、Kiroはプロジェクトを開いた時点でそれを読み込みます。つまり、対話する際に「このテンプレートに従って」とか毎回指示しなくても、最初から同じ前提でアプリ開発を進めてくれます。

以前のCursorやClaude Codeでは、AGENTS.mdやCLAUDE.mdを書いても自分がうまく活用できていなかったのに対して、KiroのSteeringはファイルを置くだけで自動的にルールとして機能するので、この差はかなり大きかったです。

結果として、

  • AIに「今回はこの構成で」と毎回伝えなくて済む
  • プロジェクトを開くだけで、前提が共有された状態から始まる
  • 仕様整理 → 設計 → タスク分解 → 実装の流れが毎回同じになる

という状態になりました。

テンプレートの構成

なぜ Amplify x Kiro なのかというと、自分はAWSを触る機会が多く、認証・データ・ホスティングをまとめて扱いたかったので。人によっては Next.js + Supabase でも React + Firebase でもよいと思います。大事なのは「毎回戻れる型がある」こと、です。

テンプレートの構成は、ざっくりこんな感じ。

kiro-amplify-template/
├── src/                # Next.js App Router
│   ├── app/            # ページ・レイアウト
│   ├── components/     # UIコンポーネント
│   ├── hooks/          # カスタムReact hooks
│   ├── lib/            # ロジック・ユーティリティ
│   └── types/          # 型定義
├── amplify/            # Amplify Gen 2 定義
│   ├── auth/           # 認証設定
│   └── data/           # データモデル定義
├── agents/             # Strands Agent(任意)
├── .kiro/              # Kiro設定(Steering + Skills)
│   ├── steering/       # ポリシーファイル
│   ├── skills/         # スキル定義
│   └── settings/       # ワークスペース設定
├── .github/            # CI/CD・テンプレート
├── docs/               # ドキュメント
├── AGENTS.md           # エージェント向けガイドライン
└── package.json

この中で、特に重要なのは以下の部分です。

amplify/

Amplify Gen 2 のバックエンド定義を置く場所です。
認証、データ、ストレージなど、アプリに必要なバックエンドリソースをここで管理します。

個人開発では、認証やDBを毎回どう作るかで迷いがちです。
最初から Amplify Gen 2 を前提にすることで、バックエンド構築の方針を固定しました。

agents/

AIエージェントを追加する場合に利用する場所です。
かならず使う必要はなく、要件次第でAIエージェントを追加する場合に拡張先として用意してあります。

src/

フロントエンドの実装を置く場所です。
画面、コンポーネント、機能単位のディレクトリなどをあらかじめ決めておくことで、実装中に迷いにくくなります。

.kiro/

前述したSteeringやSkillsを置く場所です。
プロジェクトを開いた瞬間にKiroが読み込むので、ここに書いたルールが自動的に効きます。

docs/

設計メモや調査メモを残す場所です。

個人開発では、READMEだけでは書ききれない判断や検討過程が出てきます。
たとえば、

  • なぜこのデータモデルにしたのか
  • なぜこの機能を後回しにしたのか
  • どこで詰まったのか
  • 次にやることは何か

こうした情報を残しておくことで、後から見返しやすくなります。
また、Qiita記事を書くときの材料にもなります。

テンプレート化して一番変わったこと

テンプレートを作って一番大きかったのは、個人開発の開始コストが下がったこと です。

以前は、何か作りたいと思っても、最初に構成をコーディングAIに伝える必要がありました。

  • フロントはどうするか
  • バックエンドはどうするか
  • 認証はどうするか
  • デプロイはどうするか

毎回なんとなくイメージを持って始めるけれど、その前提をAIに伝えるのがとても億劫でした。
このあたりで迷っているうちに、作りたい気持ちが少し冷めてしまうこともありました。

しかし、テンプレートがあることで、感覚が変わりました。

「このアイデア、テンプレートに乗せれば試せそう。」

この感覚はかなり大きいです。

個人開発では、アイデアがあっても、最初の一歩が重いとそのまま流れてしまいます。
テンプレート化によって、その最初の一歩が軽くなりました。

Kiroで変わったこと・・・仕様から始められるようになった

今回のテンプレートでは、KiroのIDEを使うことを前提としています。

Kiroといえば仕様駆動開発。小さな個人開発でも仕様作成から始めることを徹底することで品質の安定化が見込めます。

個人開発とはいえ作っていくと仕様変更がちょこちょこ発生します。
そのような時にも柔軟に対応できるよう、いきなりコードを書くのではなく仕様書や設計書を整理してから開発を進めることが重要です。

特にコーディングAIの動作環境にそこまでこだわりのない方には、ある程度パッケージングされている Kiro IDE はおすすめの選択肢となります。

Amplifyで変わったこと・・・バックエンド構築の心理的ハードルが下がった

今回のテンプレートでは、バックエンドの土台として Amplify Gen 2 を使っています。

個人開発では、本当に作りたいのはアプリの機能や体験です。
しかし実際には、以下のような周辺構築で手が止まりがちです。

  • 認証をどうするか
  • DBをどうするか
  • フロントエンドとどうつなぐか
  • デプロイをどうするか

これらを毎回ゼロから考えるのはかなり重い。

Amplify Gen 2 をテンプレートに組み込むことで、

  • 認証は Cognito
  • データは AppSync + DynamoDB
  • ホスティングは Amplify Hosting
  • CI/CDパイプラインはGitHub連携

というように、大枠の構成を固定化することができます。

これにより、個人開発の関心を「インフラや周辺構築」から「何を作るか」「どう使いやすくするか」に寄せられるようになりました。

実際に作ったもの・試したこと

このテンプレートの活用を通じて、以下のようなアプリを作りました。

  • 高配当株ポートフォリオ管理アプリ
  • 日本株分析エージェント
  • ブックマーク管理ツール

さらにこれらのアプリ作成を通じて機能の深堀り・検証し、新たな知見が得られています。

テンプレートを整える
  ↓
作りたいものに適用する
  ↓
詰まったところを調べる
  ↓
学びをQiitaにまとめる
  ↓
次の開発に活かす

このサイクルができてきたことで、個人開発と学習がつながるようになりました。

例:高配当株ポートフォリオ管理アプリ

テンプレートを使って試したテーマの一つが、高配当株ポートフォリオ管理アプリです。

自分は日本株の配当情報やポートフォリオ管理に関心があり、以前からスプレッドシートやフリーのアプリを使って、株価や配当情報の収集・管理を試していました。

このテーマは、自分にとって実用性があります。
そのため、単なるサンプルアプリではなく、「自分が本当に欲しいもの」として個人開発しやすい題材でした。

このアプリでは、たとえば以下のような機能を考えました。

  • 保有銘柄を登録する
  • 銘柄ごとの配当利回りを見る
  • ポートフォリオ全体の配当状況を確認する
  • データを蓄積して推移を見られるようにする

こうしたアプリを作るとき、以前であれば、まず構成をどうするかで悩んでいたと思います。

しかし、自分用テンプレートがあることで、アプリそのもののアイディアに集中しやすくなりました。追加の機能を組み込む際も無理なく既存構成に組み込むことができました。

毎週Qiita投稿

ここ数ヶ月、毎週Qiita投稿を続けています。

ただ、これは「記事を書くこと」自体が目的というより、個人開発と学習のサイクルを回すための仕組みになっています。

テンプレートを作り、KiroやAmplify Gen 2を触り、個人開発を進めていると、自然と記事のネタが出てきます。

たとえば、

  • 自分が詰まったこと
  • 理解が曖昧だったこと
  • 実際に作ってみてわかったこと
  • 初心者目線で整理し直したこと
  • 後から見返したい設計メモ

こうしたものは、そのままQiita記事の材料になります。

AIはこの投稿サイクルでも役に立ちました。ただし、記事をAIに丸投げするわけではないです。

AIは、あくまでアウトプットの壁打ち相手。
自分の体験を記事にするための編集者のような存在だと感じています。(この言い回しはAI発信w)

技術面では、自分の理解を超えるような内容は掲載しない。自分の言葉に置き換える。
という心がけが何より重要になります。

一方で、自分の理解が足りないことを認識できたり、AIの骨子をキッカケに機能の深堀りができたり、自分にない視点を加えることができます。

難しかったこと・注意点

もちろん、自分用テンプレートを作ればすべてが解決するわけではないです。
実際に使ってみて、いくつか注意点も感じました。

テンプレートを作り込みすぎると重くなる

便利にしようとして、最初から全部入りにしすぎると、テンプレート自体が重くなります。

個人開発の初速を上げるためのテンプレートなのに、テンプレートの理解やメンテナンスに時間がかかると本末転倒です。

最初は最小限で良いと思います。必要なものを後から足せる余白を残す方が、長く使いやすいです。

AIの提案をそのまま採用しない

AIはもっともらしい提案をしてくれます。
でも、必ずしも最新の仕様やベストプラクティスに沿っているとは限らないです。

特に、AIエージェント周りの機能はアップデートが早いので、AIの回答だけを信じるのは危険です。

実際に動かして確認すること。公式ドキュメントを見ること。エラーが出たら原因を切り分けること。このあたりは、AI頼みにするとしても意識して指示する必要があります。

テンプレートも育てていく必要がある

一度テンプレートを作って終わりではないです。

実際に個人開発で使ってみると、

  • このディレクトリは使いにくい
  • AIに渡す前提をもう少し明確にしたい
  • よく使うプロンプトを残しておきたい
  • CI/CDの設定をもう少し整えたい

といった改善点が出てきます。

テンプレートは完成品というより、個人開発を通じて育てていくものと感じています。

実際に自分のテンプレートも、v1を作った後にAIエージェント周りの刷新(AG-UI、AgentCore CLI対応など)でv2に改定しました。

2026年上半期を振り返って

2026年上半期、自分の個人開発はかなり変わりました。
自分用テンプレートを作ったことで、毎回ゼロから構成を考える必要がなくなり、アイデアを試すまでのハードルがかなり下がりました。

  • テンプレートによって、個人開発の開始コストが下がった
  • Kiroによって、仕様やタスクを整理しやすくなった
  • Amplify Gen 2によって、バックエンド構築のハードルが下がった
  • AIによって、実装だけでなく記事化や振り返りまで進めやすくなった
  • Qiita投稿によって、学びを残すサイクルができた

今回一番強く感じたのは、AI活用で大事なのは「AIに任せること」だけではないということ。
むしろ、AIに頼るほど、こちら側に戻るべき型や前提が必要になります。

自分の場合、その型が Amplify x Kiro のテンプレートでした。
ただし、それはあくまで一例です。

大事なのは、Amplify x Kiro を使うことそのものではなく、自分がAIに振り回されないための標準構成を持つこと だと思っています。

個人開発で一番変わったのは、コードを書くスピードではないです。

2026年後半も、このテンプレートを育てながら個人開発とアウトプットを続けていきたいと思います。

関連記事

  • テンプレートの技術詳細

  • テンプレートv2(AG-UI / AgentCore CLI 対応)

  • 高配当株ポートフォリオ管理アプリ

参考リンク

0
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
0
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?