ヱビス@業務改善・既存Web改修

紙・Excel・チャットに散らばる業務を整理し、必要な部分だけ小さく仕組み化。既存PHP／Laravel／EC-CUBEの改修・保守にも対応しています。業務改善やWebシステムのお困りごとは、公式サイトまたはDMからご相談ください。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

「Excelとチャットで何とか回している」

「古いWebシステムを直したいが、壊れるのが怖い」

そんな中小事業者向けに、業務整理から小さなシステム化、既存PHP／Laravelの安全な改修まで支援しています。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

Laravel 13.25.0では、全Queueをまとめてpause/resumeできる仕組みが追加されました。

一方、公開後にLaravel公式リポジトリで、

・Redis Cluster
・AWS ElastiCache Serverless
・phpredis

の構成で、queue:workがジョブを取得できなくなる報告が上がっています。

原因として報告されているのは、Queueのpause状態を確認する際に複数キーをMGETする処理です。

Redis Clusterでは異なるhash slotのキーをまとめて取得できないためCROSSSLOTとなり、その後Workerがエラー→再試行を繰り返す状態になります。

現��、修正PRも出ていますが、8月12日朝時点ではまだOpenです。

該当する構成でLaravel 13.25.0へ上げる場合は、先にIssueと修正状況を確認しておいた方がよさそうです。

こういう問題はローカルの単一Redisでは再現せず、本番のCluster構成だけで出ることがあります。

Frameworkの更新時はリリースノートだけでなく、

「自分が使っているQueue / Cache / DB構成に関係する既知Issueが出ていないか」

まで確認しておくと安心ですね。

■ Laravel リリース・ノート
https://t.co/GoyADBwl5t

■ Laravel 該当Issue
https://t.co/o4tmHO3ZBv

■ Laravel 該当 プルリク
https://t.co/BQGVpWmBht

[ヱビス@業務改善・既存Web改修 @evisu_dev]

数え直したことでそこまで見えたんですね！

同じ『13件』でも、通常一覧と削除用一覧で意味が少し違っているのは、後から仕様変更が入ったときにもズレやすそうですね。

まず400系を監視して実際の失敗を拾えるようにしておくのは良さそうです。今回のやり取りが整理のきっかけになったなら嬉しいです！

[ヱビス@業務改善・既存Web改修 @evisu_dev]

「Claude Sonnet 5、9月の値上げ撤回」という情報を見かけますが、利用経路には注意が必要です。

Anthropic直のClaude Platformでは、9/1予定だった

入力 $3 → $2
出力 $15 → $10

の価格変更が撤回され、現在の価格が標準価格になりました。

ただし、Anthropic公式ドキュメントでもAmazon BedrockやGoogle Cloudの料金は各クラウドの料金表を確認するよう案内されています。

8/12時点では、Google Cloud公式料金ページにはまだ
「8/31まで $2/$10、9/1から $3/$15」
と掲載されています。

「Sonnet 5全体が値上げ撤回」と考えるのではなく、実際に使っている提供経路の料金を確認した方がよさそうです。

■ Google Cloud Pricing:
https://t.co/M5pr4POylc

[ヱビス@業務改善・既存Web改修 @evisu_dev]

既存システムを改修するときは、コードを見る��に業務側へ確認しておきたいこともあります。

たとえば、

・実際によく使われている機能
・利用が集中する時間帯
・システム外で手作業していること
・止まると特に困る業務
・以前から気になっている使いづらさ

こうした情報があると、「どこから直すか」の優先順位を決めやすくなります。

技術的に直せる順番と、業務上直したい順番は違うこともあります。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

「システムを止められないので、改修できない」と思うことがあります。

ただ、止められないことと、変更できないことは別です。

大切なのは、

・どこまでなら影響を限定できるか
・問題があったとき元に戻せるか
・切り替え後に異常を確認できるか
を先に整理することです。

改修そのものより、「安全に戻せる準備」を先に考えておくと進めやすくなります。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

システムの保守は、「毎月改修があるか」だけで考えなくてもよいと思います。

たとえば、

・障害時に相談できる人がいる
・PHPやライブラリの更新を把握できる
・小さな不具合をため込まずに済む
・急な改修でも状況説明から始めなくてよい

こうした状態を維持することも保守の役割です。

変更が少ない時期ほど、「何かあったとき誰に聞けるか」を確認しておくと安心です。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

「書き込めた」と「意図した状態で公開できた」を分けて確認するの、大事ですね。

自動化だとAPIが成功を返しても、公開状態・本文・予約時刻などが期待値とズレることがあるので、投稿後にIDを取り直して実状態を照合するところまで入れるとかなり安心できそうです。

今後は「公開確認」も別タスクとして監視する予定ですか？

[ヱビス@業務改善・既存Web改修 @evisu_dev]

Separating stable engineering rules from feature-specific instructions seems especially important here.

I’d probably keep the “best practices” document for invariants, then record architectural decisions separately with why a choice was made and what would justify changing it. Otherwise the master document can become another source of stale instructions as the product evolves.

Do you treat architecture decisions as part of the same document, or keep them as a separate history?

[ヱビス@業務改善・既存Web改修 @evisu_dev]

The interesting part is that AI reduced the cost of rebuilding enough for you to optimize for disposability rather than permanence.

Keeping posts as flat Blade files and removing the DB/CMS also gives the agent a much smaller system to reason about. I like the “manual first, automate later” choice too — it avoids adding deployment machinery before the workflow proves it needs it.

Do you think you’ll keep the architecture intentionally disposable even if the blog grows?

[ヱビス@業務改善・既存Web改修 @evisu_dev]

「項目を1つ追加するだけ」「ボタンを1つ変えるだけ」でも、既存システムでは確認する範囲が広くなることがあります。

同じデータを使う画面やCSV出力、通知処理などが別にあるためです。

改修内容の大きさと、影響範囲の大きさは必ずしも同じではありません。

少し遠回りに見えても、先に影響する箇所を確認しておくと安心です。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

PHP 8.6では、Sessionまわりのデフォルト設定が安全側へ変更される予定です。

Alpha 3時点のUPGRADINGでは、

・session.use_strict_mode: 0 → 1
・session.cookie_httponly: 0 → 1
・session.cookie_samesite: 未設定 → Lax

となっています。

どれもセキュリティ面ではうれしい変更ですが、既存システムでは「設定を変えなくても挙動が変わる」点を確認しておきたいところです。

例えばSameSite=Laxになると、cross-site POSTではSession Cookieが送信されなくなります。

またHttpOnlyが有効になるため、JavaScriptからSession Cookieを参照している古い実装も影響を受けます。

Strict Modeでは、保存先に存在しないSession IDを受け入れなくなるため、独自Session Handlerを使っているシステムも確認対象です。

PHPのアップグレードでは、

「削除・非推奨になったAPIはないか」

だけでなく、

「デフォルト���が変わったことで、今まで暗黙的に成立していた処理が変わらないか」

も見ておくと安心です。

PHP公式では、PHP 8.6 Beta 1は2026年8月13日予定です。

まだ開発版なので本番利用ではなく、既存アプリのテストを回して差分を探す段階ですね。

■ News Archive - 2026
https://t.co/o3LakWbvHS

■ PHP 8.6 UPGRADE NOTES
https://t.co/V8E2YsHmEi

[ヱビス@業務改善・既存Web改修 @evisu_dev]

引用ありがとうございます！

自分も最初は「Laravel / PHPでインストール型アプリまでいけるのか？」というところが気になって検証しました���

今回試した範囲では、既存のLaravel / PHPの資産を活かしつつ、Windows向けのインストール型・オフラインアプリとして動かす選択肢は十分ありそうでした。

まだ制約や未検証部分もあるので、そのあたりも含めて引き続き見ていきたいと思っています😁

[ヱビス@業務改善・既存Web改修 @evisu_dev]

引用ありがとうございます！

自分も最初は「Laravelでここまでできるのか？」というところから検証しました。

今回確認できた範囲では、Laravel / PHPの資産を活かしながら、Windows向けの配布やオフライン運用まで選択肢にはなりそうです。

まだ未検証の部分や制約もあるので、NativePHPを採用前提ではなく「こういう選択肢もある」という見方がちょうどよさそうです。

時間ができて触られた際の感触も気になります！

[ヱビス@業務改善・既存Web改修 @evisu_dev]

Windowsインストール型・オフライン業務アプリが、Laravel / PHPでどこまで成立するか技術検証しました。

Windows実機で、
・インストーラー生成
・オフライン動作
・SQLiteでのデータ保持
・CSV / PDF
・バックアップ / 復元
・アプリ更新時の既存データ保持
まで確認しています。

サンプルとして、顧客・作業依頼を管理する業務アプリを実装し、検証コードやWindows実機での確認記録もGitHubで公開しました。

今回の結論は「NativePHPを正式採用する」というものではなく、Laravel / PHPの資産を活かしてWindows業務アプリを構築する選択肢として、一定の成立性を確認できた、というものです。

できたことだけでなく、未検証の内容や制約も掲載しています。

検証内容はこちら👇
https://t.co/04TQ9YO6pa

[ヱビス@業務改善・既存Web改修 @evisu_dev]

That separation makes sense: keep the product vision stable while allowing the implementation to evolve.

The tricky part seems to be preventing the master document from drifting away from the code.

Does your periodic review also check for that drift, or do you update the document as part of each architectural change?

[ヱビス@業務改善・既存Web改修 @evisu_dev]

システム担当者が退職するときは、操作方法だけでなく「判断の理���」も残しておくと、その後の保守がかなり楽になります。

たとえば、

・触らない方がよい機能
・過去に問題になった箇所
・手作業で対応している処理
・変更時に確認しているポイント
・仕様書と実際の動作が違う部分

このあたりは、コードだけでは分からないことも多いです。

引き継ぎ期間が取れるうちに確認しておくと安心です。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

GitHubのPush Protectionで、Mistral AIやResendのAPIキーもデフォルトの検出対象になりました。

AIサービスや外部APIを組み合わせる開発では、扱う認証情報が増えています。.envをgitignoreしているだけで安心するのではなく、「秘密情報がGitHubへ届く前に止める」仕組みも確認しておきたいですね。

2026年8月7日の更新では、新たに以下がPush Protection対象へ追加されています。

・Mistral AI API key
・Resend API key
・PostHog OAuth access token
・APIclub API key
また、Lovable LabsもGitHubのSecret Scanning Partnerへ追加されています。

実務では、
「APIキーをコードへ書かない」
↓
「Secret Scanningで検出する」
↓
「Push Protectionでpush自体を止める」
↓
「漏れた場合は失効・再発行する」

というように、複数段階で考えておくと安心です。

特にAIエージェントへコード生成や設定変更を任せる場合、人が書いていないファイルにも認証情報が紛れ込む可能性があります。

「AIに秘密情報を書かないよう指示する」と「書かれても外へ出せないようにする」は、分けて考えておきたいところです。

https://t.co/RY3dzKyejF

[ヱビス@業務改善・既存Web改修 @evisu_dev]

AIで作ったコードが問題なく動いていても、そのまま本番運用できるとは限りません。

気をつけたいのは、画面から見えにくい部分です。

たとえば、認可の漏れ、例外時の処理、ログ、バックアップ、外部サービス停止時の動きなど。

「動くか」だけでなく、「問題が起きたときに戻せるか」まで確認しておくと安心です。

[ヱビス@業務改善・既存Web改修 @evisu_dev]

「画面の価値が下がっても、正本・API・権限・監査は残る」という整理はかなり重要だと思います。

さらにAppsでStripe接続だけでなく審査サポートまで引き受けた話を見ると、AIがUIを作れるようになっても、障害時の復旧や例外対応、顧客固有の運用判断まで最後まで引き受ける部分は差別化として残りそうです。

今後「AIに任せにくい最後の運用」は、どの領域に残ると見ていますか？