AIに頼めば、ものの数秒で大量のコードが生成されます。
まるで魔法のようですが、同時にこうも思うのです。「これ、本当に動くの？」「仕様、合ってる？」と。

大量に出力されるコードの波に飲まれず、「人間が手綱を握り続ける」ために僕が実践してきた開発のTipsを書き残しておきます。

これは、2026年の自分への手紙でもあります。
「あの頃はそんな苦労をしてたんだな」と笑って読み返せますように。

機会にできることは機械に任せる（Lint / Pre-commit / Auto Format）

AIは優秀ですが、たまにインデントを崩したり、変な書き癖を出してきたりします。
生成された大量のコードを目視でレビューして「ここ、スペース空いてないよ」なんて指摘するのは、人間のやる仕事じゃありませんよね。

だからこそ、Lint と Pre-commit、そして 自動フォーマット は必須でした。

• 保存＝整形（Auto Format）
  エディタで保存した瞬間に、コードが綺麗になる設定はマスト。AIが吐き出したコードを貼り付けた瞬間、プロジェクトの規約に合わせて「シュッ」と整う快感。これがないと精神衛生が保てません。
• コミット前の門番（Pre-commit）
  Gitにコミットする前に、Linterが自動で走るように設定しました。型エラーや未使用変数は、人間が気づく前に機械に弾いてもらう。

「コードの見た目」や「単純なミス」に脳のメモリを使わない。これがAI時代を生き抜く第一歩でした。（AI開発がどうっていう話ではないがより一層重要になっている

実装指示は細かくStepByStep形式

最終的なゴールを明示したうえで、StepByStepで実装させました。

ゴールは .documents にMarkdownを配置し、その仕様書通りになるように指示をします。

## As Is

## To Be 

## Task

## Remarks

1. 〇〇を最終ゴールとします。実装方針を出して。
2. ツッコミを入れる
   • Step1の実装のセキュリティホールは？
   • タイムアウトの条件は〇〇に
3. テスト書いてもらう
4. もちろんRed
5. テストのレビュー
   • テスト問題なければ実装
   • 問題あれば2を見直す
6. テストがGreenになるような実装

この辺はガイドラインやコーディング規約などを整備すればよかったのかなぁと考えている反省点です。

テスト戦略：AIに任せる部分、僕が譲らない部分

ここが一番のキモです。
AIはコードを書くのは早いですが、「僕たちが本当に作りたいもの」を100%理解しているわけではありません。
だからテストの役割分担をこう決めました。

単体テスト（ViteTest / PHPUnit）

関数単体や小さなロジックの検証には、ViteTestやPHPUnitを使いました。
ここはAIにも手伝ってもらいやすい領域です。「この関数のテスト書いて」と言えば、エッジケースまで網羅したテストを提案してくれます。

※ 単体テストをAIに書いてもらうために、関数は限りなく小さくするような単一責任の原則でAIに実装してもらっています。ぜーんぶAIです。

Featureテスト（結合・機能テスト）は「僕」が書く

けれど、機能全体が正しく動くかを確認するFeatureテストだけは、僕自身の手で書くようにしました。
これには明確な理由が2つあります。

1. コードの理解：
   AIが書いたブラックボックスなコードも、テストを書く過程で読み解く必要があります。「どう動くべきか」を定義するのは人間です。
2. 要求仕様の達成：
   求められている「要件」を満たしているか判定できるのは、今のところまだ人間だけです。

「AIにコードを書かせるなら、人間はテスト（仕様）を書け」 これが2025年の僕の合言葉でした。
テストが通る＝仕様を満たしているという安心感があって初めて、AIのスピードを享受できるんです。

2026年の僕へ

どうですか？ 2026年の開発現場は。

AIが仕様の矛盾すら指摘して、テストまで完ぺきに書いてくれるようになっているのでしょうか。

もしそうなっていたとしても、2025年の僕は「正しく動くものを届けたい」という一心で、Linterを設定し、Featureテストを書いていたことを覚えていてください。

エンジニアとしての仕事に楽しさは残っていますか？2025年末では、だんだんと辛くなってきています。

それじゃ、また。良い開発ライフを！

とにかくエネルギーが凄い

もう最初に伝えたい。スタートアップの社長はとにかくエネルギーが凄い。凄すぎる。

どうにか売上を立てるために毎日毎日走り回っている。

それが起因しているのかとにかく毎日変わった情報を持ってきて違うことを実践しようとする。ついこの前のミーティングで決まった事とは違う内容の指示が飛んできたりする。

もう、怖いのですよ。物凄く。

サラリーマン的な考えがまだ強く残っているのか、一度決まったことに対してはあまり疑問に思わない事が多々ある自分にとって、状況が常に変わるのはかなり体力がいる。

これは社長に対しての悪口というわけではなく、変化に強くならなければ生きていけないということへの自分への戒めである。社長に対してもそうだし、事業への売上に対してもそう。
とにかく変化に強くなり、対応力を上げていかなければ生き残れないんだなぁと。

やるべきこと

スタートアップの社長というものはとにかくエネルギーが凄い。これは間違いない事実だ。

社長のエネルギーに圧倒されないためにも、基礎的なことを徹底していかなければいけない。

議事録の作成一つとっても「前回はこれが決定されていましたよ」の一言が言える状況を常に作って置かなければいけない。

正直な話、議事録がどうのこうの言っている時点で自分のレベルが如何に低いかが思い知らされる。（まぁ言い訳としては議事録なんて取っている暇ねぇーよ

とにかく先回りして準備して、とにかく事業を前に進める。その気概を常に持ち続ける必要があるんだろうな。

自分は小心者なので、数字を持てていない状況で誰かに意見を出すのは気が引ける。とにかく数字を出そう。そうすれば何か変わるはずだ。

後輩ちゃんから AWS におけるデータ保持の方法ってどうなってるんですか？ というざっくりとした質問を受けました。

後輩の疑問点としては、データを保持するサービスが複数出てきて、それがなんのためにあるのか？どのようなユースケースがあるのか？がわからなくなったとのことです。

• EBS
• EFS
• S3

確かに質問されてみるとぱっとは回答ができなかったので、改めて学習し直してみました。

EBS

特徴

• EC2インスタンスに直接アタッチして使用する仮想ハードディスクのようなもの。
• EBSとEC2は 1：1 の関係
  • インスタンス間で共有は出来ない
• 容量を動的に変更できる
• EC2 の一部ではない。ネットワーク接続を通してEC2インスタンスにアタッチされる。
• RDSのストレージにも使われているよ
• DockerのVolumeをAWSに管理させているイメージ

ユースケース

• データの書き換えが頻繁に行われるアプリケーション

まー、一般的なウェブシステムとかで使われていると思ってもらえればええんちゃいますの。

EFS

特徴

• 複数のEC2インスタンスから同時にアクセスできるファイルストレージ
• 自動スケーリング
• 複数のデータセンターでレプリケートされるので高可用
• POSIX互換なので、Linux で標準的なファイルシステムのように使える
• 直接アクセスることが出来ない
  サブネット内にマウントターゲットを設置する必要がある

ユースケース

• 複数のインスタンスで共有する必要のあるファイルストレージ
• コンテンツ管理
• ログファイルの共有
• ホームディレクトリの管理

僕が経験したのは、バッチ関連のファイルをEFSを用いて複数EC2で使用する運用を経験しました。

cronの設定は各インスタンスで行う必要があるのですが、cronで叩かれる実行ファイルはEFSに保管しているファイルを叩くというような構成です。

（個人的にはLambdaでええんちゃいますのと思った案件でした

S3

特徴

• 大量のデータを保存するのに適したストレージ
• ファイルをオブジェクトとして保存し、キーを付与する
  • KVS
• 世界中からHTTP/HTTPS アクセスできる
• バージョニング ← これメチャクチャ便利！使ってみてほしい、。
• ライフサイクル ← これも便利

ユースケース

• 静的なWebサイトのホスティング
• 画像、ビデオなどのメディアファイルの保存
• バックアップやログの長期保存

汎用性が高いため、なんだかんだでS3は使いがちです。

保険明細の管理や本人識別書の管理といった個人情報をS3で保管するといったことも運用も経験しました。

便利が故にアクセスポリシーなどの設定を間違えてしまうと重大なセキュリティインシデントになりかねないサービスでもあるなぁというのが所存です。

まとめ

ユースケースごとに使用されるサービスが異なってくるのはなんとなく理解してもらえたでしょうか。

かゆいところまで手が届くようにしているAWSさんは凄いっススス

make: *** [Makefile:196: /var/tmp/imagick/Imagick_arginfo.h] Error 1
ERROR: `make INSTALL_ROOT="/var/tmp/pear-build-rootEHkAY7/install-imagick-3.7.0" install' failed

悔しい。

Imagick のインストールに必要な以下がインストールされていることを確認したのだけど、うまくいかなかった。

php-devel php-pear gcc make
ImageMagick ImageMagick-devel

makeできていないことが問題だと考えたので、ソースのビルドもやってみたが上手くいかなかった。苦しいぜ。

何よりも悔しいのが、何が原因で落ちているのかが分からないこと。

これ以上時間かけても解決できそうにないので、優秀な人達の解決策が出てくるの待ちます（他力本願ですみませぬ。。。

追記：2024-08-26

PHPのバージョンを8.3→8.2にダウングレード後にimagickのインストールを行うと正常終了した。

バージョン互換性に難があったぽい。

インストール時に使用されている Parser 等にも変化があったので、恐らく互換性の問題だろうと考える。

AmazonLinux2023は何も悪くなかった。

1. 概要
   • やりたいこと
   • エラー
2. 確認

概要

やりたいこと

モジュールのインストール

エラー

Error Summary
————-
Disk Requirements:
At least 39MB more space needed on the / filesystem.

確認

du -sh /* 2>/dev/null | sort -rh | head -n 10
4.0G /swapfile
1.6G /usr
1.4G /var
361M /home
43M /opt
39M /boot
35M /root
22M /etc
460K /run
364K /tmp

スワップを多めに取っていたことを忘れていたぜ。

セキュリティサポートが2022年末に終了して久しいPHP7系で動いているシステムが乗っかているサーバーの移行タスクです。

事の発端

CentOS 7のサポート終了がきっかけです。

DevOps系のお仕事に携わっている人なら理解してくれると思うのですが、サポートが切れた技術を継続して使用していくことの恐ろしさったら中々のものです。

まぁそんな事情があったので、CentOSを別のOSに移行していこうー！というノリで始まりました。

困ったことに

クラウドサービスはAWSを選択しているので、AWSが提供しているOSであるAmazonLinux2023を移行先のOSとして決定しました。

単純なLAMP環境を構築することが今回のタスクだったので、作業をガシガシ進めていくと一つの問題にぶち当たりました。

PHP7系がインストールできない…

Remiリポジトリ, EPELが使えない

そもそもの問題としてPHP7系は2022年末にサポートが切れているので、AmazonLinuxがサポートしている訳がありません。
普通に考えてみれば至極真っ当です。

今回のタスクでは、PHP7系を使うことは外せない要件として上がっていたので、どうしてもPHP7系が必要です。

こうなったらRemiリポジトリから持ってくるしかないなーと思っていた矢先、Remiリポジトリも使えないとのこと。（EPELがそもそも使えないため

AWS ドキュメント
EPEL
CentOSなどで使う、RemiRepositoryってなんだ？

今回の要件（PHP7系 install）を達成する事は、Amazonlinux2023 では不可能だと知った瞬間でした…

OS選定

CentOS の移行先で検索すると以下のOSたちがよくヒットしました。

• RedHatEnterpriseLinux
• AlmaLinux
• RockyLinux

PHP7系 が使えること 及び 互換性があること , ある程度の認知度 があるOSを選択したかったので、 RockyLinux で行くことに決定しました。

最終的にはRockyLinux上でRemiリポジトリを使用して目的の環境を作成することができたよーん。

感謝を捧げる

振り回された感が拭えないタスクだったのですが、誰が悪いとかはないなーという所感です。

CentOSのサポートが切れるのも、Amazonlinux2023 がPHP7 をサポートしていないのも、PHP7を使って未だに運用しているシステムも誰も悪くないです。
（PHP7に゙関しては早くバージョンアップしてほしい…

最終的には何とかなったので、 RockeyLinux のコントリビューターに感謝を捧げます

1. 概要
2. 調査
   • Intervention IMage
   • minio への通信
3. 原因

概要

個人開発で使用している以下スタックで画像を保存できない問題がおきた。

• Laravel10
• MinIO(S3の代わり)
• Intervention IMage 3

調査

Intervention IMage

Intervention IMage がVersion2 → Version3 で大きく変わったこともあり、使用法を疑ったが、何ら問題はなかった。

debug等の値を見て見たが、問題なし。。。

    /**
     * 画像をリサイズする.
     *
     * @param \Illuminate\Http\UploadedFile $file
     * @return \Intervention\Image\Interfaces\ImageInterface
     */
    public function resize(UploadedFile $file): ImageInterface
    {
        return $this->ImageManager
            ->read($file)
            ->resize(Media::BLOG_IMAGE_WIDTH, Media::BLOG_IMAGE_HEIGHT);
    }


    /**
     * 画像をS3にPutする.
     *
     * @param string $path
     * @param \Illuminate\Http\UploadedFile $file
     * @return bool
     */
    public function putForS3(string $path, UploadedFile $file): bool
    {
        $convertFile = $this->ImageManger->resize($file)->toPng();
        return $this->diskS3->put($path, $convertFile);
    }

minio への通信

ローカル環境をDockerを用いて開発していることもあり、ローカルネットワークが怪しいと何故か閃いた。

以下のコマンドを用いてネットワークを見たところ、同じネットワーク内に存在していたのでコンテナ間の通信は担保されている様子でした。

docker network ls
docker network inspect

ただし、 minio に向けた curl コマンドが返ってこないことが分かった。

原因

調査を進めていくと、サービス名に対してエンドポイントを指定しないといけないことが分かった。

minio:
    image: quay.io/minio/minio:RELEASE.2023-01-18T04-36-38Z
    container_name: 'discovery-gem_minio'

今回はminioとして登録していたので、 .env のエンドぽいとの指定が以下の様に設定する必要がありました。

AWS_ENDPOINT=http:{docker-compose.ymlで指定したport}//minio

たったこれだけのために頭を悩ましたのは悔しすぎる。

1. 症状
2. 結論

症状

• 取得したドメインでブラウザからのアクセスができない
  • パブリック IPv4 DNSではアクセスできる
  • 3日前くらいまではアクセスできていた
  • curl からも帰ってこない

結論

メールアドレスの検証をしていなかった。
Route53 > 登録済みドメイン

再送信後、検証を実施したら意図した挙動になった。

curl やら dig , whois なんかを見て回ったので3時間位とかした。
単純なミスでした。（心の底から泣いた。

個人開発で良かった。忙しいとしょうもないところもできなくなるね…

今回は、ソフトウェア開発の一環として非常に重要なインフラストラクチャ（以下、インフラ）についてお話ししたいと思います。

多くのプログラマーがコードを書くことに夢中になる一方で、インフラについてはあまり関心を持たないことがあります。
しかし、インフラに興味を持つことは、より強力でスケーラブルなアプリケーションを作成するために不可欠です。

インフラとは？

インフラとは、ソフトウェアが動作するための基盤となるハードウェア、ネットワーク、ストレージ、クラウドサービスなどを指します。これには、サーバーの設定、ネットワークの構築、データベースの管理、スケーリングのためのクラウドサービスの利用などが含まれます。

なぜインフラに興味を持つべきか？

1. パフォーマンスの最適化: インフラの知識があると、アプリケーションのパフォーマンスを最適化するための適切なリソースを選択し、設定することができます。
2. 信頼性の向上: 適切なインフラの設計は、アプリケーションのダウンタイムを最小限に抑え、信頼性を向上させるのに役立ちます。
3. スケーラビリティ: インフラを理解していると、トラフィックの増加に対応できるスケーラブルなアーキテクチャを設計することが可能です。
4. セキュリティの強化: インフラのセキュリティを強化することで、アプリケーションを攻撃から守ることができます。
5. 多角的な課題解決: プログラム以外の手段として、インフラの変更や最適化を考慮することで、課題解決の選択肢が増えます。例えば、コードの最適化だけでなく、サーバーのスケールアップやネットワーク設定の見直しも有効な解決策となります。

具体的に考えてみよう

例えば、あるウェブアプリケーションのパフォーマンスが悪く、ユーザーからのクレームが増えている状況を考えてみましょう。

この場合、最初に考えるのはコードの最適化かもしれません。
効率的なアルゴリズムを使用したり、データベースクエリを最適化することが効果的です。

しかし、これだけが解決策ではありません。

インフラ観点で考えてみましょう。

サーバーのスケールアップ

現在のサーバーがトラフィックに対応しきれていない場合、サーバーのスケールアップ（より強力なサーバーにアップグレード）を検討できます。

これにより、リソース不足によるパフォーマンス低下を防ぐことができます。

例えば、EC2インスタンスのサイズをt3.smallからt3.largeに変更することで、CPUとメモリリソースが増加し、パフォーマンスが向上する可能性があります。

ロードバランシングの導入

トラフィックが特定のサーバーに集中している場合、ロードバランサーを導入することで、トラフィックを複数のサーバーに分散させることができます。これにより、各サーバーの負荷が軽減され、全体のパフォーマンスが向上します。

AWS Application Load Balancer（ALB）を使用して、複数のEC2インスタンス間でトラフィックを分散することで、スケーラビリティと信頼性を向上させることができます。

また、ALBではパスルーティングを設定することが可能なため、重たい処理専用のサーバーで処理をするといったことも考えることができます。

その際にはログイン情報を引き継ぐといったことも考える必要が出てくるため、Redisなどのミドルウェアも視野に入れる必要があります。

サーバーレスの選択

AWS Lambda といったサーバーレスアーキテクチャを選択することも視野に入れると良いです。

サーバーレスを利用することで、サーバーの管理が不要になり、スケーリングも自動で行われます。

（Lambdaには制約があるので注意。この記事わかりやすいよ

キャッシュ戦略

結果をキャッシュサーバーに格納していこうぜぇぇぇ

ネットワーク設定の最適化

ネットワークの設定を見直し、遅延を最小限に抑えるための最適化を行うことも重要です。

例えば、コンテンツデリバリネットワーク（CDN）を使用して、静的コンテンツをユーザーに近い場所から提供することで、応答時間を短縮できます。

CloudFrontを利用して、画像やJavaScriptファイルなどの静的リソースをキャッシュし、グローバルに分散されたエッジロケーションから提供することで、ユーザー体験を向上させることができます。

具体的に何を学ぶべきか？

1. サーバー管理: Linuxの基本的なコマンド、サーバーのセットアップ、SSHの使用方法を学びましょう。
2. クラウドサービス: AWS、Azure、Google Cloudなどの主要なクラウドプロバイダーのサービスについて理解し、使いこなせるようにしましょう。
3. コンテナ技術: DockerやKubernetesなどのコンテナ技術を学ぶことで、アプリケーションのデプロイメントが効率的になります。
4. ネットワークの基礎: IPアドレス、サブネット、DNS、ロードバランシングなどの基本的なネットワーク概念を理解しましょう。
5. インフラストラクチャー・アズ・コード（IaC）: TerraformやCloudFormationを使用して、コードでインフラを管理する方法を学びましょう。

最後に

インフラの知識は、プログラマーにとって非常に有益です。

コードを書くことだけでなく、そのコードが動作する環境について理解することで、より優れたソフトウェアを作成することができます。
さらに、プログラム以外の手段としてインフラを活用することで、課題解決の幅が広がります。ぜひ、インフラに興味を持ち、自身のスキルセットを拡充していきましょう。

このブログが皆さんのインフラへの関心を高めるきっかけとなれば幸いです。次回もお楽しみに！

1. 前提
2. 既存のセッションから他のセッションに切り替える方法
3. ペインの削除方法
4. ペインの強制削除
5. セッション開始
6. セッション名変更

前提

•  - は同時押し
•  + は単独の実行

既存のセッションから他のセッションに切り替える方法

すでに tmux セッション内にいる場合、以下の手順で他のセッションに切り替えます：

1. Prefixキー (デフォルトでは Ctrl-b) を押す。
2. s キーを押してセッション一覧を表示する。
3. 矢印キーで目的のセッションを選び、Enter キーを押してそのセッションに切り替える。

ペインの削除方法

1. 削除したいペインにフォーカスを合わせる: Ctrl-b を押して、矢印キーを使って削除したいペインにフォーカスを移動します。
2. ペインを削除: Ctrl-b + x

ペインの強制削除

1. exit

セッション開始

tmux new -s 'session-name'

セッション名変更

tmux rename -t 変更前セッション名 変更後セッション名