コーダーの仕事はAIでなくなるか：見積りの行で見る減る作業・残る作業

WordPress や HTML/CSS のコーディングで食べている人が「AI でこの仕事はなくなるのか」と不安になったときに、見積りの行ごとに「減る作業」と「値段が付く作業」を仕分けられるようにする記事です。結論から言うと、縮むのは「書く時間」で、「確かめる・測る・決める・責任を持つ」作業は残り、むしろ見積りに書き出さないと取りこぼします。工程ごとの早見表、納品前のチェック用スクリプト、表示速度の報告のひな形、AI で速くなった分を値下げしない見積りの例を持ち帰れます。

結論：縮むのは「書く時間」、残るのは「確かめる・決める・責任を持つ」作業

AI で「書く」工程は縮むことが多い一方、出力の確認と修正で縮んだ分が相殺される場合もあり、そのまま納品できる場面はまだ多くありません。仕事がなくなるかどうかは、自分の見積りのどの行で稼いでいるかで決まります。

開発者の側の数字を見ます。Stack Overflow の 2025年の開発者調査では、AI ツールを使っている・使う予定の人は 84%（前年 76%）で、プロの開発者の 51% が毎日使っています。一方で、AI の出力の正確さを「信用しない」は 46%、「信用する」は 33% で、「強く信用する」は 3.1% にとどまりました。

同じ調査で最も多い不満は「ほぼ合っているが、完全ではない解」の 66% で、「AI が書いたコードのデバッグのほうが時間がかかる」も 45.2% ありました。書く作業が速くなった分、確かめて直す作業が残っている、というのが現場の実感に近い数字です。

発注する企業の側はどうか。IPA（情報処理推進機構）の「DX動向2026」（2026年4〜6月に調査、1,799社が回答）の発表では、AI の導入は大企業を中心に広がり、多くの企業で効果が実感されている一方、「期待どおりや期待以上の効果の割合は限定的」とまとめています。お客は「AI で速く・安く」を期待しつつ、成果の出し方はまだ手探りの段階です。

つまり、制作者がやるべきことは「AI を使えます」と言うことではありません。AI で縮んだ時間を何に振り替え、その結果お客に何が届くのかを、見積りと納品物で見せることです。

見積りの行ごとに見る：AI で縮む作業・縮まない作業

コーディングの工程を見積りの行に分けると、AI で大きく縮むのは「答えの形が決まっている作業」で、縮みにくいのは「お客の事情を聞かないと答えが決まらない作業」と「事故の責任を負う作業」です。下の早見表は、手元の見積書の行と突き合わせて使ってください。

見積りの行	AI での縮み方	人に残る作業	値段の付け方の例
カンプの HTML/CSS 化	大きく縮む	崩れの確認、ブラウザ・端末の確認、命名の統一	ページ単価より「確認範囲（端末・ブラウザ）」を明記
レスポンシブの調整	縮む	実機での確認、中間の幅での崩れ	確認する端末の一覧を見積りに添付
JS の小物（タブ・アコーディオン）	大きく縮む	キーボード操作・読み上げの確認	アクセシビリティの確認を別の行に
WordPress のテーマ化	縮む	テンプレートの階層の判断、既存プラグインとの干渉	テーマの設計書を納品物に
カスタム投稿・フィールドの設計	ほぼ縮まない	更新する人・頻度・権限を聞いてデータの形を決める	設計の打ち合わせと設計書で1行
表示速度の改善	一部縮む	測定、原因の切り分け、改善前後の報告	目標値と測定の報告を成果物に
キャッシュ・CDN の設定	書くのは縮む	ログイン中・カート・フォームを壊さない確認	設定と動作確認の記録で1行
フォーム・メール送信	一部縮む	迷惑メール判定、届かないときの切り分け	送信テストの記録を納品物に
サーバー・DNS の移行	ほぼ縮まない	メール（MX）を止めない手順、切り戻し	移行手順書と当日の立ち会い
保守（更新・バックアップ）	調べものは縮む	更新の判断、復元の確認、事故時の対応	月額の範囲と対応時間を契約で決める

表の右の2列が、AI が速くなっても値段が付く部分です。「書く」行しか見積りにない人ほど、AI の影響を正面から受けます。逆に、確認・測定・設計・移行を別の行に書き出している人は、AI で書く時間が縮んでも、その分を他の行に振り替えられます。

AI の出力は納品前に確かめる：よく抜ける4点と確認スクリプト

AI が書いたマークアップは見た目が整っていても、表示速度とアクセシビリティに効く属性が抜けやすいので、納品前に機械的に確かめます。Google の web.dev の解説が勧めている点と、WCAG（ウェブアクセシビリティの国際的な指針）の基本を、次の4点に絞ります。

1. 画像の width と height。書かないと、画像が読み込まれるまで場所が確保されず、文字が下にずれます（CLS の悪化）。web.dev は「画像と動画には常に width と height の属性を付ける」と書いています。
2. 最初に見える大きな画像を遅延読み込みしない。web.dev は「LCP の画像は決して遅延読み込みしない」と明記しています。AI はすべての画像に loading="lazy" を付けがちです。
3. LCP になりそうな画像に fetchpriority="high"。ただし web.dev は、1〜2枚を超えて付けると効果がなくなると注意しています。
4. alt とフォーカスの見た目。alt のない画像（WCAG 1.1.1）と、outline: none でフォーカスを消したまま代わりを用意しない CSS（WCAG 2.4.7）は、よく混ざります。

この4点を見る小さなスクリプトです。依存するライブラリはなく、Node.js があれば動きます。正規表現で見る簡易版なので、テンプレートから組み立てるページは、ブラウザで表示したあとの HTML を保存して渡してください。2つ目の引数で、LCP の画像を「何枚目か」か「src の一部」で指定します。指定しないときは、2と3の確認をしません。

// check-markup.mjs  使い方: node check-markup.mjs page.html [LCP の画像の番号 か src の一部]
import { readFileSync } from 'node:fs';

const html = readFileSync(process.argv[2], 'utf8');
const lcpArg = process.argv[3];
const imgs = [...html.matchAll(/<img\b[^>]*>/gi)].map((m) => m[0]);
const has = (tag, attr) => new RegExp(`\\s${attr}(\\s*=|\\s|>|/)`, 'i').test(tag);
const problems = [];

// LCP の画像: 数字なら何枚目か、それ以外は src に含まれる文字列で探す。指定がなければ LCP の確認はしない
let lcp = -1;
if (lcpArg && /^\d+$/.test(lcpArg)) lcp = Number(lcpArg) - 1;
else if (lcpArg) lcp = imgs.findIndex((t) => (t.match(/\ssrc\s*=\s*["']?([^"'\s>]+)/i)?.[1] ?? '').includes(lcpArg));
if (lcpArg && !imgs[lcp]) problems.push(`LCP の画像「${lcpArg}」が見つからない`);

imgs.forEach((tag, i) => {
  const no = `img ${i + 1}`;
  if (!has(tag, 'alt')) problems.push(`${no}: alt がない`);
  if (!has(tag, 'width') || !has(tag, 'height')) problems.push(`${no}: width/height がない（CLS の原因）`);
  if (i === lcp && /loading\s*=\s*["']?lazy/i.test(tag)) problems.push(`${no}: LCP の画像が loading="lazy"`);
  if (i === lcp && !/fetchpriority\s*=\s*["']?high/i.test(tag)) problems.push(`${no}: LCP の画像に fetchpriority="high" がない`);
});
if (/outline\s*:\s*(none|0)\b/i.test(html) && !/:focus-visible/i.test(html)) {
  problems.push('CSS: outline を消しているのに :focus-visible の代わりのスタイルがない');
}

console.log(`画像 ${imgs.length} 枚 / LCP の画像: ${imgs[lcp] ? `img ${lcp + 1}` : '指定なし（確認しない）'} / 指摘 ${problems.length} 件`);
problems.forEach((p) => console.log(`- ${p}`));
process.exitCode = problems.length ? 1 : 0;

編集部で、これらの抜けをわざと入れたサンプル（ヒーロー画像1枚とカード2枚、outline: none あり）と、直したサンプルを用意し、Node.js 22 で実行しました。サンプルは説明のために作ったもので、特定の AI の出力ではありません。

<!-- 直す前（抜けを入れたサンプル） -->
<style> a, button { outline: none; } </style>
<img src="/hero.webp" loading="lazy">
<img src="/card1.webp" alt="施工事例：外壁の塗り替え" loading="lazy">
<img src="/card2.webp" loading="lazy">

<!-- 直したあと -->
<style> a:focus-visible, button:focus-visible { outline: 3px solid #1a5fb4; outline-offset: 2px; } </style>
<img src="/hero-1280.webp" width="1280" height="720" fetchpriority="high" alt="塗り替えを終えた住宅の外観">
<img src="/card1.webp" width="400" height="300" alt="施工事例：外壁の塗り替え" loading="lazy">
<img src="/card2.webp" width="400" height="300" alt="施工事例：屋根の葺き替え" loading="lazy">

$ node check-markup.mjs before.html 1
画像 3 枚 / LCP の画像: img 1 / 指摘 8 件
- img 1: alt がない
- img 1: width/height がない（CLS の原因）
- img 1: LCP の画像が loading="lazy"
- img 1: LCP の画像に fetchpriority="high" がない
- img 2: width/height がない（CLS の原因）
- img 3: alt がない
- img 3: width/height がない（CLS の原因）
- CSS: outline を消しているのに :focus-visible の代わりのスタイルがない

$ node check-markup.mjs after.html 1
画像 3 枚 / LCP の画像: img 1 / 指摘 0 件

WordPress の実際のページでは、最初の img がヘッダーのロゴであることがよくあります。ロゴ（img 1）とヒーロー画像（/hero-1280.webp、img 2）を並べたサンプルで、番号を1にすると「img 1: LCP の画像に fetchpriority="high" がない」と、ロゴに優先度を付けるよう誤って促します。node check-markup.mjs with-logo.html hero のように src の一部で指定すると「LCP の画像: img 2 / 指摘 0 件」になりました。何が LCP の画像かは、先に PageSpeed Insights の診断や Chrome の開発者ツールで確かめてから指定してください。装飾の画像に alt="" を付けるのは正しい書き方なので、指摘の対象にしていません。大事なのはスクリプトそのものより、AI の出力を受け取ったら毎回同じ観点で見る手順を持つことです。その手順が、見積りの「確認」の行の中身になります。

表示速度：基準を持って測り、報告まで納品物にする

表示速度の改善は「速くしました」では値段になりにくく、基準の数字と、改善前後の測定の報告を納品物にして初めて値段になります。基準は Google が公開しているので、自分で作る必要はありません。

web.dev が示す Core Web Vitals の「良好」の目安は次のとおりです。

指標	見ているもの	良好の目安
LCP	いちばん大きな要素が表示されるまでの時間	2.5秒以内
INP	操作してから画面が反応するまでの時間	200ミリ秒以下
CLS	読み込み中のレイアウトのずれ	0.1以下

判定は、ページの読み込みの75パーセンタイルで、モバイルとデスクトップを分けて見ます。つまり「自分の PC で速かった」ではなく、実際の訪問者の4分の3がこの数字に収まっているかで判断します。INP は 2024年3月に FID に代わって Core Web Vitals の指標になりました。

お客への説明で気をつけたいのは、検索順位との関係です。Google 検索セントラルの文書は「Core Web Vitals は、その他のページ エクスペリエンス要素とともに、Google のコア ランキング システムがランキングを決定する際に考慮する要素」と書いています。考慮される要素の一つであって、良くすれば順位が上がると約束できるものではありません。提案では「順位」ではなく「訪問者の待ち時間とずれを減らす」ことを成果にします。

表示速度の報告のひな形

納品のときに、次の形でお客に渡します。数字を埋めるだけで、毎回同じ品質の報告になります。

【表示速度の改善 報告】
対象ページ: トップ / 事例一覧 / お問い合わせ（URL は別紙）
測定に使ったもの: PageSpeed Insights（モバイル・デスクトップ）、Search Console の「Core Web Vitals レポート」
目標: LCP 2.5秒以内 / INP 200ミリ秒以下 / CLS 0.1以下（75パーセンタイル）

          改善前（測定日: ）  改善後（測定日: ）
LCP（モバイル）
INP（モバイル）
CLS（モバイル）

行ったこと:
- ヒーロー画像の遅延読み込みを外し、優先度を上げた
- 画像に寸法を指定し、読み込み中のずれをなくした
- （その他）

注意:
- PageSpeed Insights の実測（フィールド）データは過去28日分の集計のため、改善後の数字が揃うまで時間がかかります
- 検索順位の変化を約束するものではありません

PageSpeed Insights の上に出る実際の訪問者のデータは、過去28日の集計です。改善直後はラボの数字（Lighthouse）で前後を比べ、1か月後に実測を追加で報告する、という2回の報告を見積りに入れておくと、作業の価値が伝わりやすくなります。

キャッシュと CMS の設計：AI に書かせるほど、人の判断が要る

「キャッシュで速くして」「カスタムフィールドを作って」と頼めば、AI はそれらしい設定やコードを出します。しかし、何をキャッシュしてはいけないか、どんなデータの形にすべきかは、サイトの運用を知らないと決まりません。ここが、AI が速くなっても単価が下がりにくい作業です。

キャッシュで起きやすい事故

ページのキャッシュは、うまくいくと劇的に速くなる一方、設定を誤ると「別の人の画面を返す」「フォームが送れない」事故になります。WordPress で AI の出した設定を使う前に、次を確かめます。

確かめること	起きうる事故	確かめ方・目安
ログイン中の人の応答をキャッシュしていないか	管理バーや会員情報が他人に見える	ログインした状態と、別のブラウザ（ログインなし）で同じページを開き比べる
カート・注文・マイアカウントを外しているか	他人のカートの中身が見える	WooCommerce の文書は Cart・My Account・Checkout の除外を求めている
WooCommerce の Cookie を除外しているか	カートの数が合わない	woocommerce_cart_hash、woocommerce_items_in_cart、wp_woocommerce_session_ などを除外対象として挙げている
フォームを含むページのキャッシュの寿命	送信が「期限切れ」で失敗する	WordPress の nonce の有効期間は既定で12〜24時間
消すとき（purge）の範囲	更新したのに古いページが出続ける	使う CDN の文書で、どの範囲が消えるかを確認

nonce は WordPress がフォームや操作の正当性を確かめるための使い捨ての値で、公式の文書では既定の寿命は1日ですが、実際に有効なのは12〜24時間です。フォームのあるページを1日以上キャッシュすると、古い nonce を配り続けることになります。こうした確認は、AI の出力を読んだだけではわからず、実際にログインしたり、カートに入れたりして試すしかありません。

CMS の設計で聞くこと

カスタム投稿やカスタムフィールドのテンプレートは AI がすぐに書けますが、「どの項目を、誰が、どのくらいの頻度で更新するか」はお客に聞かないと決まりません。設計の打ち合わせでは、少なくとも次を聞きます。

• 更新する人は誰か（社内の担当者か、外注か）と、その人の操作の慣れ
• 更新の頻度と、公開前に確認する人がいるか（権限と承認の流れ）
• 一覧で並べ替え・絞り込みたい項目（日付、地域、カテゴリなど）
• 将来、別の CMS やサイトにデータを移す予定があるか

聞いた内容は「テーマの設計書」として納品物にします。投稿タイプ、フィールド名と型、必須かどうか、テンプレートとの対応を表にしたものです。この設計書は、後でお客や別の制作者が AI に作業を頼むときにもそのまま読ませられるので、保守の引き継ぎのときにも価値が残ります。

保守：脆弱性と PHP の期限で、仕事は減らない

AI がコードを速く書けるようになっても、公開済みのサイトを安全に動かし続ける仕事は減りません。見つかる脆弱性の件数は前年より増え、公開から悪用までの時間も短い（中央値5時間）という集計があります。

セキュリティ企業の Patchstack が 2026年2月25日に公開した報告（同社のデータベースの集計）では、2025年に新しく見つかった WordPress まわりの脆弱性は 11,334件で、前年より 42% 増えました。91% がプラグイン、9% がテーマで、WordPress 本体は6件（いずれも優先度は低い）でした。公開の時点で修正版がなかったものが 46% あり、よく狙われた脆弱性は、公開から大量の悪用までの中央値が5時間でした。

PHP の期限も、保守の提案の材料になります。WordPress.org は PHP 8.3 以上を推奨しています。PHP 7.4 以上でも動くものの、古い版は公式のサポートが終わっていて、サイトがセキュリティ上の危険にさらされうると書いています。php.net によると、各版のサポートの期限は次のとおりです。

PHP の版	通常のサポートの終了	セキュリティ修正の終了
8.2	2024-12-31	2026-12-31
8.3	2025-12-31	2027-12-31
8.4	2026-12-31	2028-12-31
8.5	2027-12-31	2029-12-31

8.1 以前は、すでに php.net のサポート対象の一覧にありません。8.2 で動いているサイトは、2026年12月31日でセキュリティ修正も終わります。版を上げるとプラグインやテーマが動かなくなることがあるので、ステージングで試してから本番に反映する作業が必要です。これは AI に調べものを手伝わせても、実際に動かして確かめる人が要る作業です。

保守の棚卸しのコマンド

サーバーで WP-CLI が使えるなら、引き受けたサイトの状態を数分で棚卸しできます。オプションは WP-CLI の公式の文書で確かめたものです。

# WordPress 本体の版と、本体のファイルが改ざんされていないか
wp core version
wp core verify-checksums

# プラグインの一覧と、更新の有無・更新先の版
wp plugin list --fields=name,status,version,update,update_version --format=table

# WordPress.org で配布されているプラグインのファイルを照合
wp plugin verify-checksums --all

# 無効のまま置かれているプラグイン（いきなり消さない）
wp plugin list --status=inactive --field=name

PHP の版は、管理画面の「ツール → サイトヘルス → 情報 → サーバー」で確かめます。コマンドで php -v を打つと、ウェブサーバーとは別の PHP の版が出ることがあるので、管理画面の表示を正とします。無効のプラグインは、まずバックアップを取り、一定期間そのままにして問題がないか見てから削除する、という順番にします。

この出力を AI に読ませて「更新の優先順位を付けて」と頼むのは有効ですが、脆弱性の情報（Patchstack や WPScan などのデータベース）と照合して最終的に決めるのは人の仕事です。月額の保守では、更新の頻度、脆弱性情報の確認、PHP の版上げ、バックアップからの復元の確認を、それぞれ範囲として書き出しておくと、作業が見える形で値段になります。範囲の書き方は「ホームページの保守契約書の書き方」、他社が作ったサイトを受けるときの確認は「他社制作WordPressの保守引き継ぎ：受ける前に見る10項目」にまとめています。

保守の経験を積みたいのに受け先がない人は、手放したい保守を制作者どうしで渡し合う場を使う手もあります。Handoff（制作者の入口）では、保守を手放したい制作者がお客の名前やサイトの URL を伏せたまま「引き継いでほしい」を出せます。会員は月500円（税込）で、いまは試験公開中のため無料、成約の手数料はありません。

AI で速くなった分を値下げしない見積りと契約

AI で作業時間が縮んだとき、時間×単価で見積もっていると、確認や測定の行を足しても売上は減ります。値下げしないには、同じ成果物には以前と同じ値段を付け、増えた成果物を別の行で足す見積りにします。

計算の例

下層ページ5枚のコーディングで考えます。次の時間・単価・金額は、計算を見せるための仮の数字で、相場ではありません。

	行	時間	金額（例: 1時間 5,000円）
以前	書く（HTML/CSS）	20	100,000円
	ブラウザ確認・修正	4	20,000円
	合計	24	120,000円
AI を使ったあと	書く（AI の下書き＋手直し）	8	40,000円
	AI の出力の確認・修正	6	30,000円
	表示速度の測定と報告	3	15,000円
	アクセシビリティの確認	2	10,000円
	合計	19	95,000円

同じ基準で比べると、時間で見積もる限り金額は下がります。以前と同じ範囲（書く＋確認）なら 120,000円が 70,000円、測定とアクセシビリティの行を足しても 95,000円で、新しい成果物を増やしたうえで約2割の減額です。行を足すだけでは、値下げは防げません。

そこで、時間ではなく成果物の単位で値段を付けます。お客が受け取る「確認済みの下層5ページ」は以前と同じ成果物なので、以前と同じ値段にし、新しく増えた成果物は別の値段で足します。

成果物（例）	金額
下層5ページのコーディング（AI の出力の確認・確認する端末の一覧を含む）	120,000円
表示速度の測定と報告（目標値つき）	15,000円
アクセシビリティの確認	10,000円
合計	145,000円

作業は19時間のままなので、1時間あたりでは約7,600円になります（例の前提: 以前の1時間 5,000円）。AI で縮んだ時間は値下げに回さず、お客の手元に残る報告と確認に変えた、という説明ができる形です。見積書の行の立て方は、Handoff の無料の見積書の項目の例も参考にしてください。

見積りの備考に入れる文例

AI を使うかどうか、使うときに何を確かめるかを、最初の見積りの段階で書いておくと、後から「AI なら安くできるでしょう」と言われたときの説明の土台になります。

【制作の進め方について】
- 制作の一部に生成 AI を補助として使う場合があります。AI の出力は、当方が内容を確認・修正したうえで納品し、成果物の品質の責任は当方が負います。
- お預かりした非公開の情報（未公開の原稿、顧客情報、ログイン情報など）は、AI のサービスに入力しません。入力してよい範囲がある場合は、事前に書面で取り決めます。
- 本見積りの金額は、上記の確認・測定・報告の作業を含む成果物に対するもので、作業時間に応じて減額するものではありません。範囲を変える場合は、改めてお見積りします。

取引のルールとの関係

発注する側が守るルールも押さえておきます。フリーランス・事業者間取引適正化等法（フリーランス法、2024年11月1日施行）は、従業員のいないフリーランスに業務を委託する事業者に、業務の内容・報酬の額・支払期日などの取引条件の明示を求めます。この明示は、発注する側が従業員のいないフリーランスでも必要です。

一方、支払期日を納品物を受け取った日から60日以内で定める義務と、1か月以上の委託での7つの禁止行為（受領拒否・報酬の減額・買いたたきなど）が課されるのは、従業員を使用する発注事業者（法律の言葉では「特定業務委託事業者」。法人は役員が2人以上の場合も含む）だけです。従業員のいないフリーランスどうしの発注では、課されるのは取引条件の明示だけ、という点に注意してください。

2026年1月1日には、下請法を改正した取適法（中小受託取引適正化法）が施行されました。公正取引委員会は、中小受託事業者から価格の協議を求められたのに応じなかったり、必要な説明をしなかったりして一方的に代金を決めることを禁止する、と説明しています。あわせて、資本金の基準に加えて従業員数の基準（取引の種類により300人・100人）が設けられ、手形払いも禁止されました。

「AI で速くなったはずだから」という理由で、発注後に一方的に報酬を下げられたり、協議に応じてもらえなかったりした場合は、これらのルールに関わる可能性があります。ただ、どちらの法律が当てはまるか、どの行為が違反にあたるかは、取引の条件や当事者の規模によって変わります。個別の判断に迷ったら、弁護士に無料で相談できる「フリーランス・トラブル110番」（厚生労働省の委託で第二東京弁護士会が運営、電話 0120-532-110、平日 9:30〜16:30）や、公正取引委員会の窓口に相談してください。

小さな制作会社が外注に出す側に回るときは、同じルールを守る立場になります。発注書の書き方は「フリーランス新法の取引条件明示テンプレート」を参照してください。

経験3年前後のコーダーが、この半年で積むとよいこと

「上流に行け」「ディレクターを目指せ」と言われても、いまの案件を回しながら職種を変えるのは簡単ではありません。いまの案件の見積りに、値段が付く行を1つずつ足していくほうが現実的です。

期間	積むこと	見積りに足せる行
1か月目	自分の過去3件の見積りを、上の早見表の行に分け直す	（棚卸し）
1〜2か月目	PageSpeed Insights と Search Console で測り、報告のひな形で1件報告する	表示速度の測定と報告
2〜3か月目	AI の出力を確かめる手順（スクリプトと目視の項目）を決めて毎回使う	AI の出力の確認・修正、アクセシビリティの確認
3〜4か月目	ステージングで PHP の版上げとプラグインの更新を試し、復元まで確かめる	PHP の版上げ、バックアップからの復元の確認
4〜6か月目	カスタムフィールドの設計書を1件作り、納品物にする	CMS の設計と設計書

AI を使う前提を整えることも、この半年の仕事に入れます。自分のコーディングの規約（命名、ブレイクポイント、画像の書き方）とテーマの設計書を文書にしておくと、AI に毎回それを読ませるだけで、出力のばらつきが減り、確認の時間も短くなります。この文書は、外注に出すときの指示書や、保守を引き継ぐときの資料にも使い回せます。

逆に、手放してよいのは「カンプを渡されて、決まった形のコードを書いて返すだけ」の受け方です。この行は、お客や発注元の社内で AI に置き換えられやすく、価格で比べられやすい部分です。同じ案件でも、確認・測定・設計・保守の行を足して受けるように変えていきます。

明日からやること

• 直近の見積書を1枚開き、早見表の行に分けて「書く」行の割合を確かめる
• check-markup.mjs を手元に置き、次に AI が書いた HTML で一度実行する
• 担当しているサイトの PHP の版をサイトヘルスで確かめ、8.2 ならセキュリティ修正が 2026年12月31日で終わること、8.1 以前ならすでにサポート対象外であることをお客に伝える
• 次の見積りの備考に、AI の使い方と確認の責任の文例を入れる