ブログ

  • 2026年を実りあるものにするための取り組み

    2026年を実りあるものにするための取り組み

    2026年がスタートしました。

    2025年もWordPressを使ったWebページの作成をしつつ、AIの波を感じながらも、わが社には導入されることなく、かなり出遅れていることに不安を感じた一年でした。

    私自身、たいした力も技術も知識もない、よくいる「モブなWeb屋」です。このままAIの波にのまれると、「モブ」としてすら存在できなくなることは明白(いまさら)。

    だいたいアラフィフにもなると磨かれた武器が1つや2つはあって、まだまだバリバリそれを振るっていく人や、最前線を退いて後進育成という形で継承していく人だったりするわけです。

    ただ、「モブなアラフィフ」には、その武器がない…。

    いや「WordPress」という武器っぽいものを持ってはいるが、その武器の強さは初期装備レベル…。

    2026年は武器を増やす

    ということで、2026年の私はあわてて使える部武器を1つでも持とうかなと思ってるところです。

    やることリスト

    • WordPressの保守サービスを始める
    • Claude Codeを使っていく
    • WordPressについてもっと深く知る
    • Webデザインを学びなおす(ツールも)
    • CSSを学びなおす
    • ウェブ解析士としてアピールする
    • ウェブ解析の学びを深める
    • セキュリティについての知見を高める
    • Webサービスをリリースする
    • Xでの発信を増やす
    • ブログを書く
    • 社名で「AIを使って何かできないか」を常に考えて、社内で「AIの人」的認知を取る

    あとは実行するだけ

    リストにあげたものは、あくまでも大項目。

    実際WordPressに関しても、ブロックテーマについて扱えるようになりたい。とか、プラグインの開発をしたい。とか、あるわけです。

    それらの細かいことがどこまでできるかわかりませんが、2026年が終わったころには「やったぜ2026年!」と言えるくらいになってればいいなと。

    12項目もあげてしまいましたが、あとは実行するだけ!

  • WordPressのLPを固定ページではなく独立ファイルで作った理由

    前回、HTMLをWordPressを利用して表示する方法を3つ紹介しました。
    そして、その中で、固定ページにLPを組み込む方法を実践していました。

    でも…

    実際に見てみると、HTMLと固定ページと全く見た目が違う…。

    原因はWordPressのテーマのCSSが干渉していたこと。

    そもそも利用しているテーマはサイドバーがあるし、ヘッダーもフッターもあるし。

    ここからHTMLと同じ見た目にするには、テーマのCSSが干渉しないようなテンプレートを作成する必要がありました。

    うん、それはめんどくさそうだ。

    ということで、別の方法として、HTMLのまま表示する方法で表示することにしました。

    独立ファイルにした理由

    HTMLのまま表示するようにした理由ですが

    1. テーマの影響を受けない
    2. 元のデザインがそのまま使える
    3. スタイル調整が不要

    こういったメリットがあります。

    WordPressを利用してるかと言われると、ちょっと微妙ですがこういった方法もあるということを知っていると、いろいろ応用が利きます。

    HTMLファイルを利用する具体的な手順

    1. /lp/ディレクトリを作成してファイルを入れる
      (index.html, style.css, mv.png)
    2. index.htmlindex.phpに変換
    3. wp-load.phpを読み込む
    4. wp_head()wp_footer()を追加
    5. Contact Form 7のショートコードを埋め込む

    お問い合わせフォームがいらなければ、4ステップで出来上がります。

    メリット

    • 完全に独立したデザイン
    • 管理がシンプル
    • Git管理もしやすい

    PHPファイルで管理するので、WordPressのテーマに影響をうけません。

    そして、固定ページではないのでGitで管理することも可能です。

    デメリット

    • WordPressの管理画面から編集できない
    • ファイルを直接編集する必要がある

    ただ一方で、WordPressの管理画面から編集することはできないので、ちょっと手間に感じることもあるかもしれません。

    まとめ

    HTMLファイルをWordPressを利用して表示する方法のうち、HTMLファイルをそのまま利用する方法を紹介しました。

    特にLPなんかの場合は、今回のように独立したファイルで作るほうが自由度が高いので向ていると思います。

    WordPressのテーマの影響は受けませんが、ショートコードだったり利用することができるので、そういった点でもベストな方法だと思います。

    ただし、

    <?php require("./wp/wp-load.php"); ?>

    を記述するのを忘れないでくださいね。

  • WordPressにLPを組み込んでみた

    Claude Codeを利用して、LPを作ってもらいましたが、それだけでは世に放たれたことにはなりません。

    どこかのサーバーに乗せてあげないと、閲覧できないわけです。

    ただ、私はWordPressを運営しているので、このLPをWordPressを使ってみられるようにしてあげればいいんです。

    では、どうやったらLPをWordPressで表示することができるのでしょうか。

    表示のさせ方は3種類

    今回の方法と同じように、AIを使ってHTMLを作成したところまでできたけれど、それをWordPressを使って表示させるにはどうしたらいいか。

    実は表示のさせ方は3種類あります。

    • 固定ページを利用する
    • pageテンプレートを利用する
    • HTMLのまま利用する

    では、それぞれ方法を確認していきましょう。

    固定ページを利用する

    WordPressの固定ページ機能を使って、LPを表示させます。

    やり方としては、LPのHTMLソースの<body>~</body>の間をコピーして、固定ページの本文欄へ「カスタムHTMLブロック」を用意して、貼り付けます。

    これだけ。

    ただし、注意しないといけないん点があって、それは利用しているWordPressテーマに依存する部分が出てくるということです。

    ヘッダーやフッター、サイドバーといったレイアウトはテーマに沿うので、LPで見ていたものとはちょっと違う見え方になってしまいます。

    とりあえず、表示してみたい。という場合にはいいかもしれませんね。

    pageテンプレートを利用する

    WordPressには固定ページ独自のテーマファイルを作ることができます。

    例えば、LPの内容を投稿した固定ページのスラッグを「lp」とした場合、page-lp.phpというテーマファイルを作ってあげると、LP専用の見た目を作ることができます。

    方法としては、「固定ページを利用する」と同じで、LP用の固定ページのHTMLを貼り付けます。

    このままだと、固定ページを利用したときと同じですが、page-lp.phpを編集するといろいろと変更できます。

    page-lp.phpにもともと何が記載されているかにもよりますが、例えばサイドバーを表示するようになっているなら、その部分をバッサリと削除。

    そうすると、ほかの固定ページではサイドバーが存在するのに、LP用固定ページだけでは、サイドバーが存在しない。ということもできてしまいます。

    PHPファイルを編集するので、若干の知識は必要ですが、固定ページを利用するよりは、多少自由度が上がります。

    HTMLのまま利用する

    WordPressを利用したいのにHTMLのまま利用する。

    いったい何を言っているのかわかりませんが、もうこのHTMLファイルのまま、WordPressを表示しているサーバーにアップしてしまいます。

    はい、それで表示できればOK!

    ですが、このままだと、もしWordPressで利用しているお問い合わせフォームプラグインを埋め込みたいとなっても利用できません。
    だって、HTMLですし。

    そこで、まずはHTMLファイルの一番上に

    <?php require("./wp/wp-load.php"); ?>

    を挿入しましょう。

    そして、</head>の前に

    <?php wp_head(); ?>

    </body>の前に

    <?php wp_footer(); ?>

    そして、お問い合わせフォームはショートコードで表示します。

    <?php echo do_shortcode( 'お問い合わせのショートコード' ); ?>

    これで、HTMLのままWordPressがこっそり内蔵されたLPを表示することができます。

    いろんなメリットデメリット

    3つ方法を紹介しましたが、だんだんと後半に行くにつれて自由度は高まってきますが、その分ファイルを編集したりする手間が増えます。

    WordPressの管理画面に入れば修正できたことができなくなってきますよね。

    逆に最初のほうはWordPressの管理画面から編集できるし、ただコピペするだけの簡単作業。

    ですが、利用しているテーマにデザインレイアウトの自由度が縛られてしまったりします。

    一長一短、どちらがいいか。は、決めきれませんが、もともとLPを作るときにWordPressテーマを意識させて作ることができれば、最初の方法でも十分魅力的なLPをWordPressの固定ページで表示できるかもしれませんね。

    ぜひ、あなたにあった方法を探してみてください。

  • Claude CodeでWordPressのLPを1週間で作った話

    AIを使えば、かんたんにLPができあがる!

    そんな時代がとうとう来ましたね。

    私も情報だけはいろいろと収集してはいたものの、会社でもAI禁止されてるし、なかなか実践できずにいました。

    「すごそう!便利そう!」

    だけど

    「ほんとにすごいの?便利なの?」

    ということで、WordPressの保守サービス用のLPを作ってみました。

    LPを作ろうと思った理由

    「WordPressの保守サービス」やりたいなぁって思ってるんですよね。

    ただ、まだ細かいところまでは考えてない。

    そもそも保守サービスだけじゃ、物足りないけれど、それも含めてAIに相談して作るところをやってみました。

    構成を決めた(12/15)

    まずは月曜日。
    構成を考えました。

    よくあるような内容ですが

    トップページ
     ├── サービス内容
     ├── 料金プラン
     ├── お問い合わせ
     └── ブログ(別で運用)

    こんな形でどうかと、AIにも相談してみたところ、いいんじゃないかと返答もらいました。

    でもちょっと待てよと。

    あえてページを分ける必要もないんじゃないか?
    内容も大してないし、LP風にしてしまったほうがいいんじゃないか?

    と考え直して、再度AIに相談。

    完璧な判断です!
    LP(ランディングページ)1ページ構成、最初はこれが絶対に正解です。

    おぉ、だったら最初からそう言ってくれよ…。

    そこからはさらに進めて、各セクションに掲載する内容を決めていきました。

    Claude Codeを初めて使った(12/16)

    今まで使っていたのはClaude。

    そしてProプランに加入しているのは、Claude Codeを使ってみたかったから。
    そしてようやくその時が来ました。

    何か月支払ったことか…。

    ほかのサイトを参考に、Claude Codeを無事インストール。
    サブスクリプションプランになってるはずだから、料金も安心。

    これで、私もAI使える人に一歩近づいた気がします。

    なんでもAIさんが開発してくれるぜ!
    そんな気分です。

    1日で全セクション生成(12/18)

    サイトの構成も決まって、各セクションの内容も決まった。
    Claude Codeもインストールできた。

    となれば…

    やることは…

    Claude Codeにサイトを作ってもらう!

    各セクション同じような感じでプロンプトを繰り返します。

    「サービス内容」セクションのHTMLとCSSを作ってください。
    site-plan.mdの内容をしっかり把握して、反映してください。

    そうそう、構成と内容をsite-plan.mdというのにまとめておいて、それをClaude Codeに参考にしてもらって、LPを作ってもらいました。

    何度か繰り返して、ようやく完成。

    見た目は、 AIっぽいデザインだけど、まず完成を優先ということで、OKです。

    さぁ、次はWordPressに組み込んでいきましょう。

  • Git環境構築と最初のつまずき

    「これからはGitの時代だ!」

    「Gitが使えないやつは、この先行きていけない!」

    なんて、「今更そこですか?」な感じのことを最近ヒシヒシと感じます。

    Gitを薄く浅くなぞっただけで、SourceTree使わないと使えなかったり、結局エラー出てコミットできずにそのままあきらめたりすることもあったり、そんなこんなで「Git怖い…」な私が、しっかり身につけられるように、やってみることにしました。

    GitHubアカウント作成でrecaptchaに2日連続で阻まれた

    まずはGitHubアカウント必要ですよね。
    ということで、GitHubアカウント開設さくっとやってしまい…開設…できない…。

    https://github.co.jp

    情報を入力して、紐をつなげるreCaptchaのクイズにも答えたにも関わらず、エラー。

    「ブラウザを変えてお試しください」という感じだったので、翌日別のブラウザから再チャレンジ。

    またも紐をつなげるreCaptchaのクイズに満点で正解するも、エラー…。

    こう何度も理由がわかりにくい部分で弾かれてしまうと、一気にやる気が無くなってしまいますよね。

    「そういえば…」と以前作ったGithubアカウントを思い出して、新しくアカウント作成はやめて、そちらを使うことにしました。

    Gitをインストールした

    続いて、パソコンへGitのインストール。

    これはもう何も迷うことなく、「Download」ボタンからexeをダウンロード。

    クリックするだけで、自分のPCにあったインストーラーがダウンロードされるようです。

    ダウンロードされたexeを実行してインストール開始。

    なんだか躓きそうなところもあったけれど、無事インストール完了しました。

    でもちょっとほんとにこのままインストールしていいのかな?と思ったので、後でもう少し詳しく調べています。

    初めてのリポジトリを作成、初めてのコミット

    さて、Githubアカウント作って、Gitインストールしたら、とりあえずコミットしないと!

    ということで、Githubサイトでリポジトリを作成。

    で…

    どうやってコミットするの?ということですが、まずは、ローカルのリポジトリを決めるところから。

    C:\Users\ユーザー名\work\

    どこがいいのかよくわかりませんでしたが、ここに置くことにしました。

    まずはCloneから

    git clone https://github.com/user/repository.git

    これで、workフォルダの中にリポジトリ名のフォルダができました。

    その中に入っていた、README.mdを編集。

    編集が終わったら更新の確認

    git status
    On branch main
    Your branch is up to date with 'origin/main'.
    
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
            modified:   README.md
    
    no changes added to commit (use "git add" and/or "git commit -a")

    そういえばブランチとか何も考えてなかったけど、まあとりあえずよし。

    README.mdが編集されてるのを確認。

    そしたらコミット!

    git commit -m "プロジェクト開始"

    じつはこの前に、変更をステージングしないといけないのですがすっかり忘れてました。

    Author identity unknown
    
    *** Please tell me who you are.
    
    Run
    
      git config --global user.email "you@example.com"
      git config --global user.name "Your Name"
    
    to set your account's default identity.
    Omit --global to set the identity only in this repository.

    コミットしたら、Author identity unknownエラー。
    「お前誰だよ」って怒られてしまいました。

    git config --global user.email "メールアドレス"
    git config --global user.name "名前"

    で、登録して再度コミット!

    Enumerating objects: 5, done.
    Counting objects: 100% (5/5), done.
    Writing objects: 100% (3/3), 288 bytes | 288.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
    To https://github.com/username/repository.git
       d2bedd5..ceec1a2  main -> main

    コミット成功!

    Githubのページでも更新を確認して、黒い画面からのコミットができました。

    そもそもGitの設定細かくわからないので調べてみた

    今回、Gitをインストールするときにいくつかのサイトを参考にしました。

    ただ、その中でよくわからなかったのが、「Scalar」ってのが追加されているところ。

    「大規模リポジトリ」ってどれくらいが大規模なのかすらわからない。

    「OPENSSH」ってなんだ?

    参考サイトを見ていると、「そのままNextを押してインストールしましょう」と書いてあるけれど、確かに今までそれに流されてきたけど、実際何を意味しているのか、ちょっと調べてみようかな。

    ということで、インストールの項目を1つずつ調べてみました。

    • Additional icons
      • On the Desktop:デスクトップにGitのアイコンを作成するかどうか
    • Windows Explorer integration
      • Open Git Bash here:右クリックメニューに「Git Bash here」を追加
      • Open Git GUI here:右クリックメニューに「Git GUI here」を追加
    • Git LFS (Large File Support)
      • 大容量ファイル(画像、動画など)を効率的に管理するための拡張機能
    • Associate .git* configuration files with the default text editor
      • .gitconfigなどの設定ファイルをデフォルトのテキストエディタで開けるように関連付け
    • Associate .sh files to be run with Bash
      • シェルスクリプト(.sh)ファイルをBashで実行できるように関連付け
    • Check daily for Git for Windows updates
      • 毎日自動的にアップデートをチェック
    • Add a Git Bash Profile to Windows Terminal
      • Windows TerminalにGit Bashのプロファイルを追加
    • Scalar (Git add-on to manage large-scale repositories)
      • 大規模リポジトリを高速化するためのツール

    まったくもって意味が分からない。

    Windows11 で右クリックメニューが使いにくくなってしまったので、
    「Windows Exploler integration」はチェックを外すことを推奨します

    [Git] Git for Windowsのインストール #Git – Qiita

    ということで、これは外しておきました。

    少し進んで、エディターの選択。

    これ何も考えず、vimにしたんですが、VS Codeとか選択肢にあったんですかね…。

    失敗したわ…どこで変えたらいいのやら…。

    続いてリポジトリ。

    何やらmasterリポジトリじゃなくて、mainリポジトリに変わっていくらしいので、先どってmainリポジトリにしました。

    続いて、PATH環境変数の設定。
    これよくわからないですよね。PATHが通ってないとかなんとか言われたりして、適当に追加したりするけど、いまいち何やってるのかはわかっていません。

    • Use Git from Git Bash only (Git Bashのみで使用)
      • 最も安全だけど制限的なやつ
      • Git BashからしかGitコマンドを実行できない
      • WindowsのコマンドプロンプトやPowerShellでは使えない
    • Git from the command line and also from 3rd-party software
      • Git Bash、コマンドプロンプト、PowerShellすべてで使える
      • SourceTreeなどのサードパーティ製ツールもGitを認識できる
      • 必要最小限のツールのみPATHに追加されるので安全
      • Use Git and optional Unix tools from the Command Prompt
        • 上級者向け
        • GitだけでなくUnixツール(find、sortなど)もPATHに追加
          Windowsの標準コマンド(findやsort)を上書きしてしまう可能性がある

      こんな良くわからない設定は、真ん中の一番いい感じの一択。

      次に、SSHクライアントの選択。

      Use external OpenSSHのほうは、独自にSSHの設定をしないといけないようなので、問題外。

      バンドルされてるほうを利用します。

      SSHの次はSSL。

      Windowsって書いてあるし、後者を選んでしまいそうだけど、企業向けらしい。
      Windowsの証明書ストアを使用するということで、これまたよくわからにので、バンドルされてるやつ。

      そして、私が悩むのが改行コードの設定。

      なんの変更もしていないの、FTPソフト使ってダウロードしてきたら、変更マークいっぱい!

      何かと思ったら改行コードが違う。

      改行コード揃えたら変更マーク消えるけど、結局これはコミットするの?しないの?
      なんて、悩むことも時々あったり。

      • Checkout Windows-style, commit Unix-style
        • チェックアウト時:LF → CRLF に変換(Windows用)
        • コミット時:CRLF → LF に変換(リポジトリはUnix形式)
      • Checkout as-is, commit Unix-style
        • チェックアウト時:変換しない
        • コミット時:CRLF → LF に変換
      • Checkout as-is, commit as-is
        • チェックアウト時もコミット時も変換しない

        2番目のはMacやUnixで推奨設定らしい。

        Windows環境は1番目がおすすめらしいですが、そういう部分気にしたくないので、何もしない3番目を選びました。

        続いて、GitBashを使うときのターミナルの選択。
        いやそもそもGitBashって何よ…な感じなのですが。

        • Use MinTTY (the default terminal of MSYS2)
          • こちらがより高機能なターミナル
          • ウィンドウサイズを自由に変更できたり、テキストを自由な形で選択できる
            (え?もう一方はできないの?)
          • 日本語などが正しく表示される
          • Windowsのコンソールプログラム(interactive Pythonなど)を使う場合はwinptyコマンドが必要
        • Use Windows’ default console window
          • Windowsの標準コマンドプロンプト(cmd.exe)を使用
          • Windowsのコンソールプログラムがそのまま動く
          • 日本語表示に追加設定が必要
          • ウィンドウのリサイズが制限される
          • テキスト選択が矩形のみ

        何に使うのかよくわかってないけど、前者一択かな。

        次は、プルしたときの動作。

        あぁ、Fast forwardとかリベースとか聞いたことはある。
        でも何のことかはわからない。

        • Fast-forward or merge
          • Fast-forward可能な場合 → Fast-forwardする(履歴が一直線)
          • Fast-forward不可能な場合 → マージコミットを作成
          • 柔軟で、ほとんどの状況に対応できる
          • マージコミットが増える可能性がある
        • Rebase
          • ローカルのコミットをリモートの最新コミットの上に「付け替える」(リベース)
          • Fast-forward可能な場合はそのまま
          • 履歴が一直線で綺麗になる
          • 慣れていないと混乱しやすい、共有ブランチでは危険
        • Only ever fast-forward
          • Fast-forwardできる場合のみpullを実行
            できない場合はエラーで停止
          • 意図しないマージを防げる
          • pullが頻繁に失敗する、手動での解決が必要

          2番目を選ぶのがよさそうな気もするけど、結局Fast forwardとリベースがなんなのかわかってないので、とりあえず1番目を選択。

          次は認証情報をどうするかで、Noneにすると、プッシュやプルのときにいちいち認証情報を入力しないといけないらしいので、前者一択。

          セキュアで現代的な認証方式らしいので。

          最後にオプションの設定。

          • Enable file system caching
            • ファイルシステムのデータをメモリにキャッシュする
            • Gitのコマンド実行速度が大幅に向上
            • WordPressプロジェクトのような中〜大規模なリポジトリに最適
          • Enable symbolic links
            • シンボリックリンクを有効化
            • 管理者権限(SeCreateSymbolicLink)が必要
            • WordPress開発では通常使わない

          ということで、前者だけ選択。

          これで、インストールの流れは終わって、無事インストールが解されるわけです。

            結局、何を言ってるのかわからない部分が多いし、納得して設定できてるかというとそうでもないけれど、無事にGitがインストールされたので、良しとしておきます。

            エディタの設定のように、あとあと変更したくなったら調べていけばなんとかなるでしょう。