はじめに
「正解」は、ひとつではない
こんにちは。株式会社 X Umbrella代表の宮川です。先日、弊社のリニューアルサイト（本サイト）を公開しました。戦略を戦略編で、デザインの設計をデザイン編でまとめてきた本シリーズの最終回として、この記事では「どう実装したか」を扱います。
対象読者は、WordPressでの制作経験があるエンジニアです。「AIをどう制作フローに組み込むか」「ブロックテーマでどこまでやれるか」を検討している方が、判断材料を得たり、実務に取り入れられる内容を目指して書きました。
はじめにお伝えしておきたいのは、デザインにもコーディングにも、「これが正解」というやり方は無いと私自身、考えています。手法は会社や人によって違いますし、何よりAIの進化が目まぐるしい今の時代は、たとえ今この瞬間の最適解があったとしても、数ヶ月後や1年後には陳腐化しているかもしれません。
この記事で紹介する方法の中にも、すでにAIでもっと簡単に対応できるものがあるはずです。なので、ここでお話しすることをそのまま受け取るのではなく、
- 自分なりのやり方に昇華させる
- AIに任せる
このどちらかの形で、あなたにとって最適な方法へ落とし込む、というつもりで読み進めてみてください。
技術スタック
| 領域 | 採用技術 |
|---|---|
| CMS | WordPress |
| ホスティング | Xserver |
| 親テーマ | unitone Pro |
| 子テーマ | unitone-child（自作） |
| ビルド | Vite 6 + Scss |
| 機能プラグイン | x-umbrella-custom（自作） |
| アニメーション | GSAP（ScrollTrigger） |
| フォーム | Snow Monkey Forms |
| エディタ / IDE | Cursor |
| バージョン管理 | GitHub |
| CI/CD | GitHub Actions |
| 機密情報管理 | 1Password |
| ローカル環境 | Local（Local by Flywheel） |
| E2E・検証 | Playwright / Chrome DevTools for Agents(chrome-devtools-mcp) |
| AI | Claude Code / Codex |
導入プラグイン
オリジナル
オリジナルで作成したプラグインの詳細については、後述します。
| プラグイン | 用途 |
|---|---|
| X Umbrella Custom | カスタムブロック・REST API・GTM連携など、自社カスタマイズの集約 |
| XU Splash | トップページ初回アクセス時のスプラッシュスクリーン |
| Multimode TOC | 目次（インライン／追従サイドバー／モバイルモーダル） |
| Page Maintenance Controller | ページ単位・サイト全体のメンテナンスモード制御 |
コンテンツ・編集
| プラグイン | 用途 |
|---|---|
| Flexible Table Block | 柔軟なテーブルブロック |
| Create Block Theme | サイトエディタの編集内容をテーマファイルに書き出し(DB→ファイル化で git 管理) |
| Snow Monkey Forms | ブロックエディタ対応のメールフォーム |
SEO対策・表示
| プラグイン | 用途 |
|---|---|
| Yoast SEO | SEO対策 |
| EWWW Image Optimizer | 画像圧縮・WebP 変換(表示速度) |
| WP Multibyte Patch | 日本語環境の互換対応 |
セキュリティ対策
| プラグイン | 用途 |
|---|---|
| CloudSecure WP Security | 管理画面・ログインURLの保護 |
| Safe SVG | SVGアップロードのサニタイズ（XSS 防止） |
バックアップ・保守
| プラグイン | 用途 |
|---|---|
| UpdraftPlus | 定期バックアップ |
| All-in-One WP Migration and Backup | サイト移行・エクスポート/インポート |
| All-in-One WP Migration Unlimited Extensio | AIOWM有料版・容量制限解除 |
| Easy Updates Manager | 更新の制御(自動更新の可否管理) |
1. クラシックテーマからブロックテーマへ
ブロックテーマはWordPress案件で多少携わっていましたが、今回はイチから本格的な実装を行なったことで、より理解を深めることができました。
結論からいうと、今までクラシックテーマ派だったのですが、ブロックテーマの利便性に気がつき、今後もブロックテーマで開発をしていきたいと思えました。
これまでは要件や予算に応じて、_s(Underscores)から自作テーマを起こしたり、Snow Monkey の豊富なフック（アクションフック・フィルターフック）を使いながらSnow Monkeyのカスタムプラグイン内でコーディングすることが中心でした。
クラシックテーマで開発を続けていた理由は、業界がブロックテーマへ移りつつある感覚はありましたが、正直、必要性には懐疑的だったためです。クラシックで十分足りていたし、本業を持つクライアントに慣れないブロックエディターで編集してもらうのはハードルが高く、デザイン品質の担保も難しい。WordPressに慣れていないクライアント様のために、カスタムフィールドで「どこに何を入れるか」が直感的に分かる入力項目を用意してあげる実装こそ、クライアントファーストだと考えていました。
しかし、一旦冷静になって考え直し、本格的に触ってから今後の受託制作に展開できるか判断する——そういう風に自社サイトをショーケース兼実験の場と位置づけ、ブロックテーマを本格採用することにしたのが、今回の大きな転換と言えます。
WordPressブロックテーマ「unitone」をなぜ選定したのか
unitone を選んだのは、同じ開発者（キタジマタカシ氏）の Snow Monkey を愛用していたことが大きいです。WordCamp Kansai 2025 に当日ボランティアスタッフとして参加した時に、キタジマ氏と直接お話する機会がありました。
その際に「Snow Monkey と unitone どちらが良いですか？」と尋ねたところ、「Snow Monkey でできなかったことが unitone でできるようになりました」と返ってきた言葉が心に刺さり、今回のテーマ決めの後押しになりました。
結果的に、デザイン編の後日談でも触れたとおり、unitone には洗練された余白やタイポグラフィがデフォルトで備わっており、デザインシステムの土台づくりが不要になるほど。それだけでなく、豊富なオリジナルブロックやパターンがあり、とても素晴らしいものでした。
2. 仕様駆動 ── 人が仕様を固め、AIが実装する
さて、ここからが本題です。
私自身、コーディングという作業が好きで楽しくて、これまでコーディングは人の手で行ってきましたが、今回は仕様は人、実装はAI、という棲み分けを試みました。その分業を機能させるための現時点の私なりのフローを解説します。
ディレクトリ構成
親テーマ unitone Pro は購入版のまま本体を改変せず(アップデート追従のため)、見た目・構造は子テーマunitone-child に集約。機能はカスタム用のプラグイン x-umbrella-custom に寄せる、という分担にしました。
├── CLAUDE.md # エントリーポイント(技術スタック・規約・作業フロー)
├── AGENTS.md # レビュー担当 AI(Codex)向けの規約
├── docs/
│ ├── design-system/ # デザイントークンの正本(色・タイポ・余白…)
│ │ └── blocks/ # カスタムブロックの設計インベントリ
│ ├── superpowers/
│ │ ├── specs/ … # 設計の正本(spec)
│ │ └── plans/ … # 実装計画
├── wp-content/
│ ├── themes/
│ │ └── unitone-child/ # 子テーマ=見た目・構造
│ │ ├── templates/ # ページテンプレート
│ │ ├── parts/ # ヘッダー・フッター等のパーツ
│ │ ├── patterns/ # ブロックパターン
│ │ ├── assets/
│ │ │ ├── src/
│ │ │ │ ├── scss/ # FLOCSS(foundation / module / …)
│ │ │ │ └── image/ # 画像
│ │ │ │ └── js/ # フロントの JS(GSAP 等)
│ │ │ └── dist/ # ビルド出力(git 管理外・CI 生成)
│ │ │ ├── css/
│ │ │ ├── image/
│ │ │ └── js/
│ │ └── style.css
│ └── plugins/
│ └── x-umbrella-custom/ # プラグイン=機能(親テーマから分離)
│ ├── blocks/ … # カスタムブロック(API v3)
│ ├── inc/ # REST / CPT / GTM / 301 / シミュレーター
│ ├── admin/ # 管理画面(React)
│ └── x-umbrella-custom.php
└── .github/
├── workflows/ # ssh_deploy_dev.yml / ssh_deploy_main.yml
└── scripts/ # deploy-mirror.sh / deploy-additive.sh仕様駆動の体制：議論 md から実装・検証まで
AI に書かせると実装は速くなるけど、判断の根拠はチャットに流れ、仕様の曖昧さがそのままコードの迷走につながってしまいます。そこで、文書で合意を作ってから段階的にコードへ落とす、という流れを規律にしました。使ったツールと担当領域は次のとおりです。
| ツール | 担当 |
|---|---|
| Claude Code | メイン実装 / 仕様・計画の下書き |
| Codex | コードレビュー・敵対レビュー |
| Figma MCP | Figmaの変数・コンポーネント・スクリーンショットの参照 |
| Playwright MCP | E2E検証（フォームやシミュレーターの実機挙動） |
| chrome-devtools-mcp | ブラウザ実機の検証・デバッグ |
実装レイヤー
- 仕様書(spec) 作成── 目的・スコープ・成功基準・アーキテクチャ・データモデルの正本
- 実装計画(plan) 作成── specをタスク単位に分解し、各タスクの実施者を明示
- 実装・検証 ── featureブランチで実装し、PR→ステージング検証
今回、重宝したのがSuperpowersというAIコーディングエージェント用のプラグインです。Claude Code で計画を立てる「Plan Mode」と同様の機能ですが、要件をヒアリングしたうえで、より仔細に計画してくれる印象です。brainstorming(議論)→ writing-plans(spec / plan ドキュメント作成)→ subagent-driven-development(実装) などを自律的に行なってくれます。
Superpowers をClaude Codeにインストールする方法
以下を実行するだけで、Claude Code の公式プラグインマーケットプレイスから導入できます。
/plugin install superpowers@claude-plugins-officialあとは何かプロジェクトを進める際に「◯◯を作りたいので、計画を立てるために必要事項をヒアリングしてください」などと自然言語で投げるだけで、自動的にプラグインを使って対話を進めてくれます。
3. unitoneにない機能をどう補ったか ── カスタムブロックと独自プラグイン
unitone 標準のブロックとパターンで大半は組めますが、当然ながら、自社サイト固有の機能まではカバーしません。足りない機能をカスタムブロックと独自プラグインの2つに分けました。
カスタムブロックを作るか、デフォルトブロックで済むか
制作したデザインを実装する際に、最初に考えるのは「そもそもカスタムブロックを作る必要があるか」です。というのも、WordPressのコアにもunitoneにも素晴らしい標準のブロックが備わっているからです。安易にブロックを自作すると、保守対象がむやみに増えるため、初期の頃は1ブロックずつ遊びながらどんな表現ができるのかを試しました。
ある程度、コアブロックやunitoneの標準ブロックの特性が分かってきたところで、カスタムブロックを作るのは、次の3つのいずれかに当てはまるときだけ、と決めました。
- 動的なデータを扱う（例：シミュレーターの計算）
- 既存ブロックの組み合わせでは実現できない挙動（例：スクロール連動、追従）
- 複数ページで再利用し、体裁を崩せないガードレールが要る（例：サービスフロー）
この3基準に当てはまらない、単なる「見た目の型」はパターン+Block Styleで登録する。ブロックとして自作するのは、コードを持つ必然性があるものだけ、という線引きです。
カスタムブロックにしたもの
x-umbrella-customには計11個のブロックが入っています。例として以下のようなカスタムブロックを作成しました。
スクロール切替（スクラブアニメーション）
スクロール位置を強制的に固定し、スクロールと連動して画像とテキストをクロスフェードで移り変わるように、アニメーション表現。
縦交互マーキー
2列交互に動く縦マーキー（無限ループ）。
制作費シミュレーター
ユーザーの入力に応じて金額を計算し、サーバーとREST通信で動的に結果を返す、費用シミュレーター。シミューレーション結果の状態を保持し、ユーザーが第三者と共有できるように、結果ページの共有用URLを発行できるようにしています。
全ブロックは block.json の API v3 で定義し、動的ブロックはサーバー側で render.php、フロントの挙動は view.js に分けます。たとえば、先ほどのスクロール切替（スクラブアニメーション）は以下のように定義しています。
{
"apiVersion": 3,
"name": "x-umbrella/scroll-crossfade",
"category": "x-umbrella",
"attributes": {
"vhPerItem": { "type": "number", "default": 300 },
"firstItemHoldVh": { "type": "number", "default": 300 },
"fadePortion": { "type": "number", "default": 0.25 }
},
"render": "file:./render.php",
"editorScript": "file:./index.js",
"viewScript": "file:./view.js"
}attributes に、スクロール量（vhPerItem）やフェードの割合（fadePortion）といった調整値を持たせておくことで、同じブロックを編集画面から数値で微調整できるようにしています。
そして、ブロックの登録は1つずつ手書きせず、build 配下の block.json を glob でまとめて拾い、一括登録しています。
foreach ( glob( XU_PATH . 'build/*/block.json' ) as $block_json ) {
register_block_type( dirname( $block_json ) );
}オリジナルプラグインにしたもの
一方、カスタムブロックではなく、独自プラグインとして制作した機能もあります。
カスタムブロック群・REST API・GTM連携などの母艦となるオリジナルプラグイン「X Umbrella Custom」の他に、以下3つのプラグインを作っています。
XU Splash（スプラッシュスクリーン）
1セッションに1回だけ、トップページにアクセスするとロゴとメッセージがフェードイン表示され、ロゴがそのままトップのヒーローセクションにあるロゴに吸い込まれる。
Multimode TOC（目次）
本記事でも表示されている目次プラグイン。
「Table of Contents Plus」などの有名な目次プラグインがありますが、ページ上部に表示されるインライン目次だけでなく、以下のことを実現したいと考えていました。
- スマホ時にも目次アイコンが表示され、タップでモーダル表示されること
- ブラウザ幅が大きい場合は、追従サイドバーにも目次が表示されていること
- Zennの記事のように、サイドバーの目次がスクロール追従し、現在読んでいるセクションが直感的に分かるUIであること
- ページタイプ（固定ページ / 投稿など）やページごとに個別設定が可能なこと
このプラグインは、検証を重ねて公式WordPressプラグインとして申請できたらと考えています。
Page Maintenance Controller（メンテナンスモード）
リニューアルサイト公開時点で一部のページがまだ完成していなかったため、別ページにリダイレクト。
単純な挙動ですが、サイト全体/特定ページのみ、どちらをメンテ状態にするか選択できたり、メンテ中のページは未認証のREST API を遮断したり、メンテ画面を固定ページ/ テンプレート使用、どちらかを選択できたり、と便利な機能を搭載しています。
こちらも調整して、公式WordPressプラグインとして申請したいと考えています。
線引きの原則
整理すると、今回の切り分けは以下のような線引きにしています。
- パターン＝ WordPressコアブロックやunitoneブロックの組み合わせ
- カスタムブロック＝ 標準ブロックでは実現できないもの——動的データ、複雑な挙動、高頻度の再利用
- プラグイン（独立）＝ サイト横断で効く機能・仕組み
極力、コアやテーマの恩恵を受けながら、しかし、それらでは表現ができない制限の枠を超えたものに関しては、自作することで実現したいことが叶いました。
4. デザインをコードにする ── AIに読み取らせ、人が仕上げる
Figma MCPで読み取り、AIに実装させる
デザイン編で作ったカンプは、Figma MCP（figma-desktop）を使ってコードに起こしました。これを通すとClaude CodeがFigmaのデザインを直接読み取ることができ、色・テキスト・レイアウトをコーディングで再現してくれます。
ただし、万能ではありません。複雑なレイアウトや、余白に込めた意図までは汲みきれないことが度々あります（Figma側のレイヤー構造を綺麗に整えれば、精度は上がる余地あり）。また今回はPCサイズのカンプしか用意していないため、AIはスマホ用のデザインを持っておらず、レスポンシブ表示は崩れがちだったため、ここは人が手で組むか、丁寧に指示してあげる必要がありました。
要所は人の手で書く
土台はClaude Codeが速くて正確です。HTML構造や基本的なスタイル、ブロックの雛形など、形が決まっていて再現性の高い部分は任せます。しかし、グラスモーフィズムやスクロール連動アニメーション（GSAP）の繊細な調整、スマホデザインがない中でのレスポンシブ実装、言語化しにくい微調整——こうした要所や仕上げは人の手で書いています。「AIに指示して直させる」より「自分で書く」ほうが速くて確実な場面は、いくつかありました。
AIである程度コーディングができても、AIの出力が正しいかを判断するために、実装の知見が必要です。
料理に例えると分かりやすいかもしれません。肉じゃがの具材をみじん切りにすれば、煮込む間に溶けて食感が失われる。食べ応えを出したいなら乱切りで切る、と目的から切り方を選びます。ラーメンの麺も、こってりしたスープには絡みやすいちぢれ麺、繊細な澄んだスープには味を邪魔しないストレート麺、と使い分ける。どちらが優れているかではなく、目的に対してどちらが適切かを判断できるかが問われます。
コードも同じです。AIが出したコードを見て「問題ない」「意図と違うから直す」と判断できるのは、自分に知見があるから。何も知らなければ、正しいのか非効率なのかも分からず、AIの提案をすべて受け入れるしかありません。AIを使いこなすことと自分で書けることは、対立せず、むしろ、コードを書けるからこそ、任せる判断ができると思います。
5. レビューと検証 ── 敵対レビューを品質ゲートに
AIに任せるほど、「一見それらしいが、どこかに穴があるコード」が量産されるリスクは上がります。なので、レビューと検証も基本はAIに任せながら、最後は人が判断する必要があります。
レビュー：工程の節目ごとに多層で挟み、鵜呑みにしない
レビューを一度きりにせず、工程の3つの節目で、粒度を変えて挟んでいます。使うコマンドも、対象に応じて使い分けました。要点は、書き手(Claude Code)とレビュアー(Codex)を分けること。同じ AI に自分のコードを見せても甘くなるので、実装は Claude、レビューは Codexに委ねました。そのうえでレビューを制作の各段に置き、実装の前後3つの接点にしています。
- 計画段階：
/codex:rescueを書き込みなし（read-only）で走らせ、specのmdファイルをレビュー - 実装：Claude Code
- コミット前：
/codex:reviewで working-tree の差分を通常レビュー(意味のあるコード塊のみ) - マイルストーンごと、PR前：
/codex:adversarial-review --base dev|mainで、実装後のコード差分を敵対的に叩く
AIが制作したもの全てを反映することもNGですが、指摘を全部反映するのも判断の放棄と同じです。AIのレビューは、鋭い指摘もあれば、的外れな指摘も、過剰な心配もあります。すべてを鵜呑みにして直していたら、コードは”レビューAI（Codex）の好み”に振り回されて、かえって歪みます。
指摘が出たら、まずその指摘自体が妥当かを人が検証し、「これは本当に問題か？」「この文脈で、そのリスクは現実的か？」を判断してから、採否を決める。このレビュー判断も知見のある人間にしかできない領域で、AIがいくら発達したとしても、エンジニアとしての知識やスキルが問われると感じました。
CodexプラグインをClaude Codeにインストールする方法
Claude Code 用 Codex プラグイン は以下を順に実行することでインストールできます。
# Codex CLI をインストール
npm install -g @openai/codex
# Codex にログイン
codex login
# Claude Code 内から実行する場合は、シェルコマンドとして実行
!codex login
# Claude Codeにマーケットプレイスを追加
/plugin marketplace add openai/codex-plugin-cc
# Codexプラグインをインストール
/plugin install codex@openai-codex
# プラグインを再読み込み
/reload-plugins
# セットアップ状態を確認
/codex:setup以降は、前述の通り、各工程の間にコマンドを実行し、レビューを依頼できます。
検証：実機でしか出ない不具合を見つける
コードレビューは、あくまでコードを読む検証なので、実際に動かしてみないと分からない不具合は、下記2つの手段で見つけました。
1. Playwright：E2E（エンドツーエンド）テスト
クリック、入力、スクリーンショット、ページ遷移、フォームテスト送信、シミュレーション検証、などブラウザを自動操作して、入力から結果表示までを通しで検証します。また、単一のブラウザだけでなくFirefoxやSafariなどマルチブラウザでのテストも可能です。
人手で毎回クリックして確かめる代わりに、シナリオを書いておけば、変更のたびに自動で確かめられます。ただし、使用するのは開発時のローカル環境のみで、本番環境では手動でテストすることをオススメします。
Claude Codeにインストールする方法
コマンドでインストールする場合：
claude mcp add playwright npx @playwright/mcp@latest手動で設定する場合：
プロジェクトのルートディレクトリに.mcp.jsonを作成して、以下を記述してください。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@anthropic-ai/mcp-server-playwright"]
}
}
}2. Chrome DevTools for Agents（chrome-devtools-mcp）：パフォーマンス分析
Chromeデベロッパーツールのコンソールエラーやネットワークリクエストの詳細取得、Core Web Vitalsの計測など行なってくれます。Playwright と同じようにブラウザの自動操作もやってくれるけど、マルチブラウザ非対応なのと、パフォーマンス分析に強みがあるので、使い分けると良いかと思います。
Claude Codeにインストールする方法
コマンドでインストールする場合：
claude mcp add chrome-devtools npx chrome-devtools-mcp@latest手動で設定する場合：
プロジェクトのルートディレクトリに.mcp.jsonを作成して、以下を記述してください。
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["chrome-devtools-mcp@latest"]
}
}
}6. 運用とDevOps——事故らない仕組み
鍵を本番環境へ直接pushしてしまう、うっかりコードに書き込んでしまう。そうしたミスを防ぐために、独自の機構を作っています。
機密情報をコードから完全に切り離す
SSHの秘密鍵やAPIキーといった機密情報を、コードやリポジトリに書かないことは普段から徹底していますが、特に、下記2系統の機密情報の扱いには気をつける必要があります。なお、この2系統の正本は常に 1Password にしています。
1. GitHub Actionsのデプロイで使う情報
サーバー・ユーザー名・デプロイ先パス・SSH鍵など。これらは GitHub Secrets に登録し、ワークフローからは ${{ secrets.MAIN_SSH_KEY }} のような参照でのみ呼び出します。ワークフローのYAMLに、平文の鍵は一切書きません。
2. ローカルでAI（Claude Code / Codex）を動かすためのAPIキー
これは .env に実キーを書かず、1Password の参照だけを置いています。
# .env には実キーを書かず、1Passwordの「場所」を指す参照だけを置く
ANTHROPIC_API_KEY="op://<vault>/<item>/credential"実行時は op run --env-file=.env -- <command> の形で、1Password CLI が参照を実キーへ解決します。.env を覗かれても、そこにあるのは op://… というポインタだけ。実キーはローカルにすら平文で記述することはありません。
デプロイは「マージ＝反映」で自動化する
デプロイの仕組みは、ブランチへの push をトリガーに自動で走ります。dev への push でステージング環境へ、main への push で本番環境へ。PRをマージすれば push が発生するので、「マージ＝デプロイ」という仕組みになっています。
転送の仕組みは、webfactory/ssh-agent と rsync の組み合わせです。webfactory/ssh-agent は、GitHub Secrets に登録したSSH秘密鍵を ssh-agent にロードするためのAction。鍵をディスクに書き出さず、メモリ上のエージェントに載せるだけなので、ワークフローの実行中も鍵がファイルとして残りません。
そのエージェント経由で rsync を走らせ、変更のあったファイルだけをサーバーへ転送しています。（この自動デプロイ設定の詳しい手順は、それだけで独立した話題になるため、本記事では概要に留めます。後日、余裕があれば別記事で解説します。）
まとめ ── 「手段」は変わったが専門的な「判断」は必要
今回、本格的にクラシックテーマからブロックテーマでの開発に乗り換えました。ヘッダーやフッター、テンプレートなども含めて、エディター上で編集を行うという操作感は、慣れるまでに時間がかかるけど、慣れてしまうとブロックテーマは制作者にとっては利便性が高いと感じました。
ほかにも、ブロックテーマとして、株式会社AnimaGateさんのHakoniwaや、株式会社ベクトルさんの X-T9、なども気になってるので試していきたいと考えています。
大事なこととしては、クラシックテーマを捨てるのではなく、予算と要件で手法を選べる状態になったこと自体が、今回の一番の収穫でした。
そして、実装編では仕様駆動の制作フローから、ブロックとプラグインの設計、レビューと検証、運用の仕組みまでを追ってきました。
戦略編では、「何を、誰に、どう届けるか」を、言葉から固めました。デザイン編では、その”届けたい印象”から逆算して、情報設計とデザインの一つひとつを判断しました。そして実装編では、AIに作業を任せつつ、仕様と品質の判断は人が行いました。
3つの記事を通して伝えたいことは、AIで「作る」ことのクオリティは上がったけれど、「何を、なぜ、どう作るか」を判断するのは、最後まで人だった、ということ。戦略の言語化も、デザインの意図も、コードの良し悪しも、判断の出どころは常に人にありました。AIは、その判断を実行に移す速度や品質を上げてくれるツールです。
裏を返せば、判断の質がそのまま成果物の質になる時代になった、とも言えます。AIの技術が発展するほど、「作る前に考え抜くこと」「作りながら判断していくこと」の価値は上がっていきます。今回の自社サイトのリニューアルは、その考え方を実証する試みでもありました。
この3編が、これからWebを作る制作会社・制作者にとって、AI時代に活躍していくための手がかりになれば嬉しく思います。
