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

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

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

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

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

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

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

「修正内容は同じなのに、会社によって見積金額がかなり違う」

こういうとき、単純に安い方を選ぶのは少し難しいです。

✅ 周辺機能への影響確認も含まれているか
✅ 動作確認や本番反映は誰が行うか
✅ 反映後に問題が出た場合、どこまで対応してもらえるか

金額の差が、そのまま作業範囲の差になっていることもあります。

まずは見積もりの前提をそろえて比較する。

金額だけでは見えない違いも、そこで分かってくると思います。

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

@may04re おお、公式URLから自動入力は便利そうですね！

ライブの公式ページって情報の書き方もバラバラなので、AIで候補を埋めて最後に確認・修正する形だと、かなり入力が楽になりそうです😄

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

@voidroom_jp あ、手動で再チェックできる形にされているんですね！

普段はキャッシュを活かしつつ、必要な時だけ更新して結果まで確認できるのは使いやすそうです。

6時間待たなくていいのは助かりますね😄

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

Gemini 2.5 Pro / FlashをAPIで使っている場合、12/1までに確認しておきたい変更があります。

Googleが11/2に提供終了の予定を発表しました。

☑ 2.5 Pro → 3.8 Flash
☑ 2.5 Flash → 3.5 Flash-Lite
☑ 2.5 Flash-Liteは今回の対象外

12/1以降、旧モデルIDへのリクエストは自動的に新モデルへ転送されます。

ただし、単純な置き換えではありません。

関数呼び出しや思考設定などに互換性のない変更があり、料金も移行先のものになります。

APIが応答しているから問題ない、とは限りません。

既存システムではモデルIDだけでなく、レスポンスの検証や料金への影響も確認しておきたいですね。

公式：https://t.co/ybuzSdmCrG

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

GitHub Actionsでpull_request_targetを使っている公開リポジトリは、12月2日から注意が必要です。

GitHubが11月2日に発表した変更で、明示的に許可するポリシーがない場合、これまで動いていたWorkflowがブロックされるようになります。

その前に、11月9日・16日（UTC）には試験的なブロックも予定されています。

日本時間では11月10日・17日の午前1〜3時です。

✅ .github/workflows内のpull_request_targetを確認
✅ Actionsの実行ポリシーと影響を確認
✅ 必要なWorkflowだけ明示的に許可

⚠️ 非公開・内部リポジトリとGitHub Enterprise Serverは対象外です。

pull_request_targetはベースリポジトリの権限で動くため、フォークPRのコードを実行していないかにも注意が必要です。

既存システムを引き継ぐときは、アプリのコードだけでなく、CI/CDの設定も確認対象にしたいですね。

公式：
https://t.co/UourQUFNBf

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

@wannameeyurubo 完成前に知ってもらうなら、機能の説明より「実際に使う場面」を体験してもらう方が伝わりやすそうですね。

返事画面だけでも、「誘われる→返事する→相手にどう見えるか」まで短いデモにすると、アプリの価値を想像しやすそうです。

最初は実際の友人に触ってもらって反応を見る予定ですか？

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

WordPress本体やプラグインの更新と、PHPランタイムの更新が別管理なのは、運用で見落としやすいところですね。

複数サイトを見ていると、PHPのバージョン・サポート期限・互換性確認の結果を台帳にしておくと、次回の更新判断がしやすそうです。

こうした情報はサイトごとに一覧で管理されていますか？

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

「画面の修正は終わりました。来週から使えます」

開発側では完了でも、現場にとってはそこから準備が始まることがあります。

操作方法の変更を誰に伝えるか。忙しい日に切り替えてよいか。問い合わせが来たとき誰が答えるか。

プログラムが動くことと、業務を切り替えられることは別なんですよね。

改修の完了日だけでなく、「いつから現場で使うか」も一緒に決めておきたいです。

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

GitHubが10月28日、定型パターンに一致しないシークレットも、コードの文脈から検知してPushをブロックする機能を公開しました。

これまでの検知では、形式が決まっているAPIキーなどが中心でしたが、今回の仕組みでは独自形式の認証情報にも対応範囲が広がります。

ただし、注意点があります。

⚠️ 現在はPublic Previewで初期状態は無効
⚠️ 対応するセキュリティ契約が必要
⚠️ AIクレジットの課金対象

シークレットは、後から削除するより、Git履歴に入る前に防げる方が扱いやすいですね。

導入するなら、検知範囲だけでなく、誤検知時の解除手順や費用も含めて判断したいところです。

公式：
https://t.co/H8Uxg3irOF

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

「顧客管理に項目を1つ追加したい」

よくある依頼ですが、入力欄を増やすだけで終わらないこともあります。

✅ 誰が入力し、後から変更できるか
✅ 一覧や検索でも使うか
✅ 過去の顧客データは空欄でよいか

ここが決まっていないと、開発途中で追加の要望が出てくることもあります。

入力することが目的ではなく、その情報をどう使いたいのか。

改修を依頼するときは、そこまで伝えておくと話が進めやすくなります。

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

Laravel Cloudが10月27日、独自ドメインのDNS設定やSSL証明書の異常を検知する機能を追加しました。

Webシステムの運用では、アプリやサーバーが正常でも、DNSの向き先が変わったり、証明書の更新に失敗したりして、サイトにアクセスできなくなることがあります。

今回のLaravel Cloudでは、

✅ A/CNAMEレコードを1時間ごとに確認
✅ SSL証明書の更新失敗を検知
✅ メールやSlackで通知

これらが全プランで利用できます。

もちろんLaravel Cloudを利用していないシステムでは、別途監視の仕組みが必要です。

既存システムを引き継ぐ際、アプリの動作確認やバックアップだけでなく、ドメインと証明書を誰が管理しているかも確認しておきたいですね。

公式：
https://t.co/BZ3KcdWMmk

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

「この機能、最近使っていないので消してもいいですよね」

古い業務システムでは、少し判断に迷うところです。

普段は使わなくても、決算時や年に一度の処理で必要になる機能があります。

利用回数が少ないからといって、不要とは限りません。

削除する前に、誰がどんな場面で使っているのか。

そもそも使われていない理由が「不要だから」なのか「使いにくいから」なのかでも、取るべき対応は変わってきます。

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

「少しだけ変更するので、問題があれば元に戻せば大丈夫です」

そう考えていたら、データの構造まで変更していて、簡単には戻せないことがあります。

改修前に確認したいのは、

✅ プログラムだけ戻せばよいか
✅ データの変更も元に戻せるか
✅ どの状態になったら戻す判断をするか

変更量が少なくても、戻す作業まで簡単とは限りません。

本番反映の手順だけでなく、問題が起きた場合の対応も考えておきたいです。

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

システムの担当者が退職しても、しばらくは何も問題なく動いていることがあります。

困るのは、普段と違う処理が必要になったとき。

月末だけ手動でデータを調整していたり、特定のエラーは担当者の判断で処理していたり。

システムの操作方法は分かっていても、例外的な対応までは引き継がれていないことがあります。

引き継ぎでは、普段の作業だけでなく「いつもと違うときに何をしていたか」も聞いておきたいですね。

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

「新しいシステムに移行したので、古いサーバーはもう止めて大丈夫ですよね」

切り替えが終わった直後ほど、少し慎重になります。

✅ 過去の注文や請求を後から確認できるか
✅ 旧システムにつながる外部連携や定期処理が残っていないか
✅ データの保存期間と保管場所が決まっているか

画面を使わなくなっても、過去のデータが必要になることはあります。

新しいシステムが動いていることと、古いシステムを停止してよいことは別の確認です。

止める前に、このあたりは整理しておきたいですね。

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

Cloudflare Durable Objectsのコード更新方式が10月30日に変更されました。

これまでデプロイ時に中断されることがあった処理や接続を、デフォルトでは最大5分間、旧コードのまま継続できるようになりました。

長時間処理やWebSocketを使うサービスにはありがたい変更です。

ただし、少し気になる点もあります。

⚠️ 5分間の処理継続が保証されるわけではない
⚠️ デプロイ直後も旧コードが動いている場合がある

例えばAPIのデータ構造を変更するとき、新旧両方のコードが一時的に動く前提で考える必要があります。

「デプロイが成功した＝全処理が新コードに切り替わった」とは限らないんですよね。

変更時には互換性や切り戻しも確認しておきたいところです。

公式：https://t.co/CjSDrEgUFh

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

GitHub EnterpriseにCopilotが含まれるようになった、という10/28の発表。

少し注意したい点があります。

一部の日本語記事では「追加の手続きなしでCopilotが使える」と説明されていますが、実際にはそうではありません。

✅ 対象のEnterprise Cloud契約ならCopilotの追加席料は0ドル
✅ ただし、管理者による席の割り当ては必要
✅ 既存のCopilot契約は自動で切り替わらない
✅ AIクレジットは付与されず、Chatなどは最初の利用から従量計測
✅ セルフサービス契約は現時点で対象外

つまり、Copilotが完全無料になるわけでも、全ユーザーが自動で使えるようになるわけでもありません。

既存のBusiness・Enterprise契約から移行する場合は、今の利用料と新しい従量課金を比較してから判断したいですね。

公式：
https://t.co/Qj4jjjLL4V

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

「ソースコードはあるので、別の会社に改修をお願いできますよね」

技術的には対応できそうでも、すぐに進められないことがあります。

開発当時の契約に、コードの改変や第三者への共有について条件が付いている場合があるからです。

別の会社へ相談する前に、まず契約書や利用許諾の内容を確認しておく。

「コードが手元にある」と「自由に引き継げる」は、必ずしも同じではないんですよね。