はじめに
みなさんの開発環境、この1年で散らかっていませんか?
私は趣味で個人開発をしていますが、気づけば以下のような状態になっていました...
- 🎨 アプリのデザインやコードがイマイチなまま放置
- 🏗️ インフラがAWS・GCP・レンタルサーバーなど複数に分散
- 🔑 APIキーが作りっぱなしでセキュリティが心配
- 📁 GitHubのリポジトリが増えすぎて管理が煩雑
- 🤖 AIのモデルがレガシー
そこで年末を機に、思い切って開発環境の大掃除をしてみました!
この記事では、アプリ・インフラ・GitHub・AI の4つの観点から、私が実際に行った整理・改善の内容を紹介します。個人開発者の方や、開発環境の見直しを考えている方の参考になればと思います!
アプリ編
デザイン改善
アプリデザインがいけてないなーと思っていましたが、なかなかいい感じのデザインを作れずに悩んでいました。そこで Figma Make という救世主に出会ったので、このツールを使っていくつかのデザインを改善しました。
既存のアプリのスクショを添付して、「いい感じにして」というプロンプトだけでいい感じのデザインを生成してくれるので、デザインセンスに自信がない人でも簡単に使えます。
以前は、v0やBolt.newを使用してデザインを作成し、FigmaにインポートするためにHTMLに変換していました。ただ、Figma Makeを使うと直接Figmaにデザインをコピペできるので、非常に楽になりました!
あとは、Claude CodeからFigmaとMCPで連携してFigmaのデザインを参照しコードを自動生成できるので、これでデザインを改善していきました。
デザイン改善後のアプリ画面例はこちらです 👇
| 🔧 改善前 | ✨ 改善後 |
|---|---|
![]() |
![]() |
| 🔧 改善前 | ✨ 改善後 |
|---|---|
![]() |
![]() |
アニメーション画像
アプリでアニメーション付き画像といえば Lottie ですが、Lottieアニメーションを自作するにはAfter Effectsが必要になることが多く、使い方を覚えるのは大変ですよね...
しかし現在では、動画をLottieアニメーションに変換することができるのです!
しかも、最近はAIで動画を作ることが簡単になったので、私も動画をAIで作り、その動画をLottieアニメーションに変換してアプリに組み込んでみました 👇
以下のツールを使えば無料でLottieアニメーションを作成できるので、ぜひ試してみてください!
動画生成:
Lovart AI では毎日100クレジットもらえるのと、さまざまな動画生成AIを使うことができるので、これで画像を動画化できます。
動画からLottieアニメーション変換:
👇 で動画をLottieアニメーションに変換して
👇 で .lottie形式にしてファイルサイズを最適化する
という流れで作成するのがいいと思います!
⚠️ 動画には透明情報を持たせることができないので、Lottieアニメーションにも背景色が付いてしまいます。そのため背景色はあらかじめ画面の背景色と合わせて動画を生成する必要があります。
Swift Packageで処理を共通化
アプリを何個も開発していると、他のアプリから流用してくる共通機能が出てきます。
例えば私は、「アプリ内の課金処理」「レビューポップアップ機能」「開発者の他のアプリリストUI」のようなものを毎回流用していたので、ここが対象となりました。
他のアプリからコードを持ってくると、どれか一つのアプリの変更に伴い、他のアプリも修正するのが大変になってきたので、Swift Package化して共通利用するようにしました。命名は ~Kit で統一しました。
私はXcode Cloudでビルドしていますが、Xcode CloudではApp Store Connectからリポジトリを許可するだけでプライベートリポジトリにアクセスできるようになります。SSHキーやPATのようなものは不要で、管理も簡単にできるのでおすすめです!
iOS 26対応
iOS 18からiOS 26ではデザインが大きく変わりましたね...
iOS 26ではリキッドグラスデザインなるものがデフォルトとなりました。
特にタブバーがフローティングのようになっているのは、デザインへの影響が大きいなーと思いました。
個人開発者の方がすぐにリキッドグラスデザインに対応するのは難しいと思います。
その場合は、Info.plistで UIDesignRequiresCompatibility を YES にすれば、一旦リキッドグラスデザインを無効にできるので、私はこの対応にしました。
ただし、この対応は一時的にAppleが許可しているだけのようでして、
おそらくiOS 27でUIDesignRequiresCompatibilityの使用ができなくなるとのことです。
iOS 27は例年通りなら2026年9月ごろにリリース予定になると思うので、それまでにリキッドデザインに対応する必要がありそうです😅
インフラ編
全てをCloudflareへ移行
これが一番の大仕事でした 💪
移行前の環境は以下の通りでした。
| サービス | プロバイダー |
|---|---|
| Webサイト | レンタルサーバー |
| ドメイン管理 | レンタルサーバー側サービス |
| 証明書 | レンタルサーバー側サービス |
| Web API | AWS Lambda |
| その他インフラ管理 | GCP |
ドメインもレンタルサーバー側のサービスで購入し、サーバーの管理も自分でやっていました。また、証明書もドメイン用に購入していましたが、Cloudflareはこの辺りを全て担ってくれるので、これを機に全部移行しました。
また、AWSのLambdaでAPIをホスティングしていましたが、Cloudflareに移行するならインフラ周りは全部Cloudflareに移行しようということで、APIもCloudflare Workersに移行しました。
移行後の環境は以下となりました。
| サービス | プロバイダー |
|---|---|
| Webサイト | Cloudflare Pages |
| ドメイン管理 | Cloudflare |
| 証明書 | Cloudflareが自動で行う |
| Web API | Cloudflare Workers |
| その他インフラ管理 | Cloudflare関連のサービス |
今後はCloudflare一本でインフラを管理できるので、精神的な負担も減り、運用も楽になると思っています!
WebAPIのフレームワークをHonoに変更
最近、Honoがアツいということを耳にしていましたが、実際に使う機会がありませんでした。Cloudflareとも相性がいいということで、APIも一新してみようと思い、Honoフレームワークを使って再構築してみました。
今後成長していくフレームワークだと思うので、長期的な運用を考えていい選択だと思っています!
APIキーの整理
いろんな場所で主にAI関連のAPIキーを使っていたため、作成しっぱなしにしたAPIキーがたくさんありました。そこで不要なAPIキーを全て削除することにしました。
また、フル権限で作成していたAPIキーには適切な権限のみを与えるようにして、不正利用されても被害が最小限になるようにしました。
例えば、OpenAIのAPIキーを持っている場合は、Allではなく、Restrictedにして、APIを呼ぶだけなら Model capabilities を Request に設定しておくといいと思います!
そして、使用するモデルのみ許可しておくと良いと思います。
GitHub編
リポジトリのアーカイブ
GitHubがこの1年でだいぶ散らかっていたので、使わなくなったリポジトリなどの整理をしました。
削除することも考えましたが、過去の資産ということでアーカイブする形で整理しました。
ただ、アーカイブしたリポジトリがぱっと見でわかりにくいので、どうしたものかと調べていると、Tampermonkeyというツールを見つけました。
Tampermonkeyは、JavaScriptを特定のページで動作させることができるChrome拡張機能です。これを使ってGitHubのページでアーカイブリポジトリを半透明にすると、以下のように視覚的にわかりやすくなります。
設定は以下を参考にすれば簡単にできます!
Topicsでタグ付け
この1年でリポジトリも増えて、だんだんと見にくくなってきたので、Topicsでタグをつけて整理しました。
タグも複数つけるとぱっと見で分かりにくくなるので、1つのリポジトリに対して1つのタグを付けるようにしました。
例えば、私の場合は以下のようなタグなどを使用して整理しました。
| タグ名 | 説明 |
|---|---|
| ios-app | iOSアプリ |
| swift-package | Swiftライブラリ |
| web-api | Web API |
| web-app | Webアプリ |
| web-site | Webサイト |
AI編
GPT-5系モデルへ移行
最近、GPT-5系のモデルがアツいですね 🔥
APIはGPT-5系の料金がGPT-4系に比べて安くなっているので、どこかで置き換えるのもアリかと思っていました。
ただ、「GPT-5系は推論モデルだから、GPT-4系よりもトークン数が多くなるし、使用料金が高くなるんじゃない?」と心配していました。しかし調べてみると、リクエストパラメーターで推論量(reasoning_effort)を調整することで、実質GPT-4系と同等程度のトークン数にできるとのことでした。
reasoning_effort は minimal, low, medium, high... と大きく分けて4段階ありますが、minimalにするとほとんど推論しないので、推論量が少なくなりトークン数も減ります。
しかも、GPT-4系と同等程度の精度が期待できたので、私はminimalを使用することにしました。
インプット料金は gpt-5-nanoは、gpt-4.1-nanoの1/2の料金となっているので、トークン数が同程度なら1/2で利用できることになります。
| モデル名 | インプット料金 (1Mトークン) | アウトプット料金 (1Mトークン) |
|---|---|---|
| gpt-5-nano | $0.05 | $0.40 |
| gpt-4.1-nano | $0.10 | $0.40 |
さらに、GPT-5系はサービスティアでflex(レイテンシはあるが使用料が1/2)を選択できるので、全体として1/2以下の料金で利用できるようになります!
| モデル名 | インプット料金 (1Mトークン) | アウトプット料金 (1Mトークン) | サービスティア |
|---|---|---|---|
| gpt-5-nano | $0.025 | $0.20 | flex |
| gpt-5-nano | $0.05 | $0.40 | default |
| gpt-4.1-nano | $0.10 | $0.40 | default |
レイテンシも正直気にならないレベルなので、個人開発で使う分には十分だと思います。
AIの生成精度に関してはGPT-4系よりもGPT-5系の方が高いと言われているので、移行を検討している方は検討してみるといいと思います!
おわりに
年末の大掃除として、開発環境やインフラ周りを整理してみました。普段は後回しにしがちな作業ですが、まとめてやると気持ちもスッキリしますね ✨
この記事を読んで何か気づきがあれば、ぜひ試してみてください!



