小規模Web制作会社の転職面談で、Cloudflareの学習や調査について説明する際のメモ。
Cloudflareの製品知識や新技術への関心を前面に出すのではなく、次の能力を伝える。
- 未知の技術を調査する
- 顧客の依頼を複数の実現方法に分解する
- AI、公式資料、最小検証を使い分ける
- 技術的に可能なことと、会社が保守できることを分ける
- 自前実装、外部サービス利用、移行、対応見送りを判断する
- AI生成アプリの保守可能性を診断する
面談後に残したい人物像は、次のとおり。
Cloudflareに詳しい人というより、未知のサービスをAIと公式資料で調査し、小さく検証して、会社が保守できる範囲まで判断できる人。
Cloudflareを学ぶ目的は、Cloudflareを導入することではない。
小規模サイトの案件に対して、次の選択肢を比較できるようにすることが目的である。
- 既存のWordPressやレンタルサーバーへ実装する
- フォームSaaSや外部サービスへ任せる
- Cloudflareへ一部の処理を分離する
- 最小構成で検証してから判断する
- 別環境へ移行する
- 保守条件を満たせないため対応を見送る
技術知識は、すべてを自分で実装するためではなく、作るもの、外部へ任せるもの、引き受けないものを判断するために使う。
Cloudflareには、小規模Web制作会社にも理解しやすい入口がある。
- DNS
- CDN
- キャッシュ
- 静的サイト公開
- Turnstileによるスパム対策
そこから次の領域へ段階的に進める。
- Workersによるフォーム受付
- 小規模なAPI
- D1によるデータ保存
- R2によるファイル保存
- 外部メールサービスや外部APIとの連携
まったく新しい環境へ全面移行するのではなく、既存サイトから独立しやすい小さな機能を使って、技術、運用、保守責任を検証できる。
問い合わせフォームであれば、次のような分離案が考えられる。
- 表示とコンテンツ管理：既存WordPress
- スパム対策：Turnstile
- フォーム受付：Workers
- 受付データ：D1
- 添付ファイル：R2
- メール送信：外部メールサービス
この構成を採用すべきだと決めるのではない。
次の条件をもとに、既存サーバーへの実装やフォームSaaSも含めて比較する。
- 顧客の予算
- 問い合わせ件数
- 個人情報の扱い
- 既存サーバーの制約
- 社内の保守担当者
- 障害時の切り分け
- 顧客アカウントの所有者
- データの退避方法
- 将来の移行可能性
Cloudflareはサービス数が多く、英語の公式ドキュメントも広範囲に分かれている。
生成AIは、未知の技術を調査可能な問題へ変えるために使う。
- 関連するサービスの列挙
- サービス間の違いの整理
- 構成案の比較
- 調査項目の洗い出し
- 英語ドキュメントの概要把握
- 検証手順のたたき台
- サンプルコードの作成
- 顧客向け説明への変換
- 現在の料金
- 無料枠
- 実行回数
- 保存容量
- セキュリティ仕様
- データ保持
- サポート範囲
- 非推奨機能
- 廃止予定
- 本番利用上の制限
- 正常にデプロイできるか
- ローカルや検証環境で再現できるか
- エラー時にログを確認できるか
- 外部サービス障害時にどう動くか
- データを退避できるか
- 元の状態へ戻せるか
- 他の担当者が引き継げるか
- 顧客案件へ採用するか
- 誰がアカウントを所有するか
- 誰が費用を負担するか
- 誰が障害対応を担当するか
- 制作会社がどこまで保守するか
- 移行や撤退をどう行うか
AIは仕様を確定する担当者ではない。
AIで調査の地図を作り、公式資料で事実を確認し、実動作で検証し、採用責任は人間が持つ。
面談では、次の説明だけでは不十分である。
Workers、D1、R2を勉強しています。
これでは、応募先の業務にどう役立つのか分からない。
次のように、案件判断へ翻訳する。
Cloudflareを調べることで、既存WordPressへ機能を追加する方法、外部サービスへ任せる方法、受付処理だけを分離する方法を、費用、障害範囲、データ管理、保守体制で比較できるようになりました。
学習内容ではなく、学習によって何を判断できるようになったかを説明する。
新しい技術を無条件に導入しない姿勢を明示する。
たとえば、次の条件ではCloudflareの採用を見送る。
- 社内で保守できる担当者が一人しかいない
- 顧客名義のアカウントを用意できない
- 費用の負担者が決まっていない
- データをエクスポートできない
- バックアップと復旧手順を用意できない
- 障害時の調査担当を決められない
- 既存の運用手順と大きく乖離する
- より単純な外部サービスで要件を満たせる
技術的に動作することと、制作会社が保守責任を持てることは分けて判断する。
Cloudflareの学習は、新規案件への導入だけでなく、AI生成アプリの保守可能性を判断するためにも使える。
今後は、顧客自身がCodex Sitesのようなサービスを使ってWebアプリを公開し、後から次のような相談を持ち込む可能性がある。
AIで作ったアプリが動かなくなった。 業務データが入っているので止められない。 少し修正して、今後の保守もお願いしたい。
この依頼に対して、画面を修正できそうだからという理由で保守を引き受けてはいけない。
- ソース一式を取得できるか
- Gitリポジトリがあるか
- 本番コードとの対応が分かるか
- 依存関係を再現できるか
- ビルド手順が分かるか
- デプロイ方法が分かるか
- D1などのテーブル定義が分かるか
- マイグレーションが管理されているか
- データをエクスポートできるか
- バックアップと復旧が可能か
- 個人情報の保存状況が分かるか
- R2などの保存先が分かるか
- ファイルとデータの対応が分かるか
- 公開範囲が適切か
- 一括取得や移行が可能か
- 顧客が管理者権限を持っているか
- ドメインの所有者が分かるか
- 外部APIの契約者が分かるか
- APIキーやシークレットを回収できるか
- 個人アカウントへ依存していないか
- ログを確認できるか
- 本番と検証環境を分けられるか
- 変更前の状態へ戻せるか
- 障害を検知できるか
- 他の担当者が引き継げるか
画面を修正できることと、システム全体の保守責任を引き受けられることは別である。
AI生成アプリの相談は、次の三つに分ける。
必要条件：
- ソースコードを取得できる
- 管理権限を確保できる
- データをバックアップできる
- 検証環境で再現できる
- ログと障害対応手順を用意できる
- 他の担当者へ引き継げる
- 顧客と制作会社の責任範囲を決められる
対象：
- 現在の環境では長期保守が難しい
- ソースとデータは回収できる
- 顧客名義の環境へ移したい
- デプロイ、ログ、バックアップを標準化したい
- 制作会社の通常の保守体制へ組み込みたい
対象：
- ソースコードを回収できない
- 顧客が管理権限を持っていない
- データ構造や保存場所が不明
- 秘密情報の所在が分からない
- 個人情報や決済情報の扱いが危険
- 本番データを壊さず変更できない
- 顧客が調査工程や費用を認めない
この場合は、責任を次の範囲に限定する。
- 現状調査
- データの退避
- アカウントと設定の回収
- リスク報告
- 再構築案または移行案の提示
保守を断ることも、顧客と制作会社を守るための設計判断である。
Cloudflareについて質問された場合は、次の順序で答える。
- 調べた目的
- 調査方法
- 検証方法
- 判断できるようになったこと
- 採用しない条件
- 制作会社の業務への接続
Cloudflareについては、導入ありきではなく、小規模サイトの選択肢を増やすために調べています。
CDNやTurnstile、静的サイト公開のような既知の用途から始め、Workers、D1、R2を使うと、既存WordPressからフォーム受付やファイル保存を分離できる可能性があります。
調査では、AIを使ってサービスの関係や比較項目を整理しています。ただし、料金、制限、セキュリティ仕様は公式ドキュメントで確認し、最小構成を作って動作を検証します。
Cloudflareを使えることより、既存環境への実装、外部サービス利用、段階導入、対応見送りを、費用、保守体制、データ管理、障害時の責任で比較できることが重要だと考えています。
また、顧客がAIで作ったWebアプリの保守相談についても、すぐ修正を約束せず、ソース、データ、権限、秘密情報、デプロイ方法を調査します。その結果に応じて、継続保守、別環境への移行、データ救出、対応見送りに分けます。
具体的な調査と検証を説明する。
- Workers、D1、R2の責務
- データとファイルの移行
- ローカル再現
- ログと障害調査
- 正常系と異常系
- バックアップとロールバック
案件進行と顧客説明へ翻訳する。
- 既存サイトへの影響
- 導入範囲
- 納期と予算
- アカウント管理
- 保守窓口
- 顧客へ説明すべき条件
受注と責任の話に圧縮する。
Cloudflareを導入することが目的ではありません。既存の制作方法では扱いにくい依頼を小さく検証し、会社が受けられる案件と断るべき案件を判断するための調査です。
Cloudflareは無料で高機能なので、今後は使うべきです。
無料枠は、本番運用と保守可能性を保証しない。
Workers、D1、R2を幅広く勉強しています。
学習内容だけでは、業務価値が伝わらない。
AIを使えば英語ドキュメントも簡単に理解できます。
AIの誤りと一次資料確認が抜けている。
WordPressをCloudflareへ置き換えられます。
応募先の既存業務を否定する印象になる。
既存環境を残す案も含め、どの機能なら安全に分離できるかを比較しています。
CDNやスパム対策として既知の用途があり、静的公開、フォーム受付、データ保存へ段階的に学習範囲を広げられるためです。全面移行ではなく、小さな機能から検証しやすい点を評価しています。
新しい技術を導入するためだけではありません。顧客の依頼に対して、自前実装、外部サービス利用、段階導入、対応見送りを比較するための選択肢を持つことが目的です。
AIは調査項目や構成案を整理するために使います。料金、制限、セキュリティ仕様などの採用判断に関係する情報は公式資料で確認し、最小構成で動作を検証します。
本番導入は避けるか、検証範囲に限定します。一人しか保守できない構成は、技術的に動作しても制作会社の標準サービスにはしません。
すぐ修正を約束せず、保守可能性調査を別工程として提案します。ソース、データ、権限、秘密情報、デプロイ、バックアップを回収できるか確認し、継続保守、移行、データ救出、対応見送りに分けます。
面談で伝える中心は、Cloudflareの製品知識ではない。
未知の技術をAIと一次資料で調査し、小さく検証する。 技術的に可能なことと、会社が保守できることを分ける。 自前実装、外部サービス利用、移行、対応見送りを案件条件から判断する。
AI時代の小規模Web制作会社では、Webアプリを作る仕事だけでなく、他者が作ったアプリを診断し、保守可能な状態へ直し、引き受ける責任を決める仕事が増える。
Cloudflareの学習は、その変化に備えるための具体的な事例として説明できる。