本日、Claude Code のスキル ccskill-gmail をオープンソース(MITライセンス)で公開しました。Claude Code から自然言語で Gmail を扱えるようにするスキルです。

 

標準で Gmail 連携できるのに？

知ってる方も多いと思いますが、Claude には Google Workspace Connector というものがあります。OAuth 認証を使って Claude に Google アカウントを紐づけるもので、この連携が Gmail を扱える MCP として機能するんですよね。

(Claude Code の /mcp コマンドから claude.ai Gmail が見える)

Claude の設定で接続しておくと、サブスク連携した Claude Code からも自然言語でメールを検索したり、下書きを書いたりできるようになります。画面には 10 tools とあって、以下がその一覧。基本的なものは揃っています。

ツール名	概要
mcp__claude_ai_Gmail__search_threads	メールを検索
mcp__claude_ai_Gmail__get_thread	メール本文・メタ情報を取得
mcp__claude_ai_Gmail__list_drafts	下書き一覧を取得
mcp__claude_ai_Gmail__create_draft	下書きを作成（添付ファイル非対応）
mcp__claude_ai_Gmail__list_labels	ユーザ定義ラベルの一覧を取得
mcp__claude_ai_Gmail__create_label	ラベルを新規作成
mcp__claude_ai_Gmail__label_message	メッセージにラベルを付与
mcp__claude_ai_Gmail__unlabel_message	メッセージからラベルを削除
mcp__claude_ai_Gmail__label_thread	スレッドにラベルを付与
mcp__claude_ai_Gmail__unlabel_thread	スレッドからラベルを削除

ただ、自分にはちょっと足りなかったんですよね。添付ファイルも扱いたいし、メール本文もPDF化したい。Claude Code に任せた作業ログも残したいし、振り返りもしたい。万が一に備えてHTMLメールに怪しい文言が含まれていたらそれも除去したい…。

標準のコネクタはそこまでの機能を持っていないので、無いなら作るかーってことで作ってしまおうと。で、ドッグフーディング(自分で使う)しながら少しずつ実装を積み重ねていくうちに、標準コネクタでは不可・面倒なことが結構できるようになりました。

機能 / タスク	標準コネクタ	ccskill-gmail
メールの検索と内容の確認	○	○
メールの下書き作成	○	○
ゴミ箱への移動	×	○
アーカイブ	×	○
未読・既読のトグル	×	○
スター付与	×	○
添付ファイルのダウンロード	×	○
メール本文の PDF 化	×	○
プロンプトインジェクション対策 (HTMLメール中の隠しプロンプト除去)	×	○
メール操作の監査ログ	×	○
マルチアカウント対応	×	○
Gmail 連携スクリプトの開発	×	○

これだけ揃ってくると、

• 取引先とのメールのやり取り履歴を時系列でまとめてもらう
• 定期的に届くPDFの内容に合わせた命名規則で特定フォルダにファイル保存してもらう
• 問い合わせ窓口になってる社内共有メアドに届くメールの整理や分析をしてもらう

みたいなことができるようになり、普段のメール作業の結構な数を Claude Code に任せられるようになってきます。/loop コマンドと組み合わせたり Hooks を工夫すれば、良い具合にメール基点の秘書的に振る舞ってくれるようになる。

(/loopで定期的な自動チェック。ニュースや通知系を無視して要返信メールを検出し、返信の下書きを作成する様子)

で、これを非エンジニアな Claude Code ユーザの方に使って頂いたところ好評だったこともあり、ちゃんと体裁を整えて公開したという次第です。(最近は非エンジニアのかた向けに家庭教師的なことをしてます)

実は(?) Gmail 操作系は既存のツール(CLI)を使う手もあるんですけどね。よく知られたものではこのあたりとか。

ツール名	特徴
gws	Google Workspace 全般の操作。公式っぽいけど厳密には公式とはされていない
gogcli	gwsが出る前はこっちが有名だった。Google 系サービス全般の操作に対応

また直近4月には Google も Google Workspace MCP サーバー を発表しています。冒頭の Claude 標準コネクタと同様に基本機能一式が揃ってる感じで、基本的な Gmail 操作なら十分です。

(Developer Preview というのもあるが、手順が多すぎて開発者じゃない限り断念するレベル…)

が、いずれもGCPの管理コンソール操作が前提になるタイプなんですよね。Gmail API を叩くのだから当然と言えば当然なんですが、個人的にGCPを触るのは好きじゃないので(手順が多い)、別のアプローチで Gmailを操作する実装を考えた次第。

非エンジニアで頑張って Claude Code を使ってるって方にも、セキュアかつ手軽に使えるアーキテクチャがないものか。

 

GCPのプロジェクト不要で Gmail を操作するアーキテクチャ

GCPでプロジェクト作ってAPIを有効化して credential を発行して配置して…は手順が多く管理が煩雑になりがちです。自分も混乱した経験があったので、APIキーに頼らない以下のような構成にしました。

Gmail を操作するロジックをGASでAPIとして実装し、OAuth認証を通過できるユーザ(つまり自分)だけが使えるAPIとしてclaspでデプロイする仕組みです。Claude Code からそのAPIを叩かせるって構図。

スキルには支援系ツールを同梱していて、

$ git clone https://github.com/feedtailor/ccskill-gmail.git
$ cd ccskill-gmail && ./ccskill-gmail setup

でセットアップ完了後、使いたい場所で、

$ cd /path/to/your-project/
$ ccskill-gmail install

とするだけで、OAuth 認証を経て、プロジェクトフォルダ配下の Claude Code が Gmail の読み書きやら添付ファイルの処理やらを行えるようになります。

スキルの中には、重要メールかどうかの判断を誤りやすいパターンや、日本語メールでのGmail操作(特に返信下書き)で発生しがちなケースについてのナレッジも内包していて、Claude Code から Gmail を操作する時にハマりやすい罠を回避しやすいようにもしています。

ちなみに個人的見解ですが、MCPやCLIがあったとしても、それらを使う際のナレッジや手順やノウハウがセットで必要になるわけで、結局スキルって形にパッケージするのがベストじゃないかと思うんですよね。なので、ccskill-gmail もAPIとナレッジを内包したスキルになってます。

普段 Claude Code を使っていて、標準コネクタでは足りないなぁと感じていた方や、非エンジニアの方でGCPとかよく分からないなぁと拒否感があったような方は、よろしければお試し下さい。

(セキュアな作りを指向して実装しています。もちろん怪しい実装は含めておらずチェックもしていますが、念のため使用前に Claude Code に「このスキルは安全か」ってな確認をしてみられることをお勧めします)

 

Claude Code のスキルを ccskill シリーズとして展開

実は昨年、ccskill-nanobanana という画像生成スキルも公開しました。

高クオリティな画像を生成できると話題になっていた Nano Banana Pro を Claude Code からスキルを介して使えるようにしたのでした。(今だと GPT Image2.0 って話もありますが…)

今回の ccskill-gmail は、ccskill-nanobanana に続く第二弾。Gmail をもっと便利に Claude Code で使いたいなぁという欲求から開発したものです。(御多分に洩れず実装はほぼ Claude Code です)

こんなふうにツール開発用途以外で、Claude Code を活用できるスキルが沢山あると良いなと思ってまして、必要に駆られて作っているものやアイディアが色々あったりしますので、今後 ccskill シリーズ として順次リリースしていきます。

サイトも作ってみました。

サイト上ではターミナルで動作する雰囲気をデモっぽく表現していたりもします。良ければご覧下さい。

近日中に、Google のスプレッドシートを操作できる ccskill-spreadsheet とか、弊社の問い合わせフォーム実装ツール espar form と連携して実際にメールが飛ぶフォームをゼロから自動生成するスキル ccskill-esparform とかの公開を予定しています。

また、ccskill シリーズの情報を発信する X (Twitter) のアカウント @ccskillx も作成してみました。LP や README には書ききれない活用法とか、シリーズ最新のスキル情報とかを発信していく予定です。こちらもよろしければフォローして頂ければと思います。

 

というわけで新たなスキルの公開と ccskill シリーズを展開しますよーってお知らせでした。あ、プレスリリースも一応打ってますのでよろしければどうぞー。

気がつけば今年も終わりですね。本年も、弊社に関わって頂いた皆様に改めて感謝申し上げます。ありがとうございました。例年通りですが、記録の意味も込めて1年の振り返りをしてみようと思います。

(今年の忘年会は、珍しいダチョウ肉にしました。美味しかった！)

 

今年は Claude Code で仕事が変わった

今年7月の19周年投稿で、コーディングエージェントAIの活用について

従業員/メンバーとしてAIを育てよう。組織のAI化を進めていこう。

ってなことを書いてまして、AIを業務に組み込む取り組みは継続しています。

自社のプロダクト開発にはもちろん、日々の雑多な作業の自動化や、ブログやプレスリリースやプレゼン資料の作成…等々、コーディングではない領域にも活用の幅は広がり、仕事のやり方が完全に変わった一年でした。Claude Code を中心に、Codex, Gemini CLI, GitHub Copilot など主だったもの一通り契約して使い分けています。

(Claude Code のページ)

振り返ってみると、2024年の「ChatGPTやGemini等のWebから使うAIに指示してコードを書かせてコピペする」スタイルから、2025年は「開発環境に常駐する Claude Code のようなエージェントAIに実装を丸投げする」スタイルに完全に変わりました。もう戻れないなと感じます。

メイン使いしている Claude Code も進化が激しく、データやノウハウもAIに扱いやすい形にするとAIがよろしく処理してくれる…というインセンティブが日々大きくなっています。ルンバのために床にモノを置かなくなるのと同じで、AIが仕事しやすい環境を整える ことにより意識が向くようになっています。

(このブログ記事も Claude Code と一緒に書いている)

例えば、ブログはCMSやDBを使わず原稿を全てファイルで管理しているので、複雑な作業もAIとの相性が抜群です。「○○のサイトのキャプチャとって、いつものパターンでこの部分に挿入して」と依頼するだけで、ブラウザ自動操作→キャプチャ取得→加工→投稿に埋め込みまで自動で間違うことなくやってくれるようになりました。AIが作業している間、自分は別の作業を並行して進める…みたいな仕事の仕方が可能になっています。

2025年は、エージェントAIが仕事をする前提で、そのクオリティを高めるために、

• 作業手順やノウハウを定義するSkillが標準化されたり
• 仕様駆動型開発(SDD:Spec Driven Development)の開発スタイルが主流になってきたり

といった動きもあり、AIにいかにうまく仕事をさせるか…を探求するフェーズに移っています。弊社もその動きを捉え、SpecKit を採用したり、定型作業をSkill化してみたりしています。

原稿中のイラストを Nano Banana Pro のAPIを使って生成させるスキル ccskill-nanobanana も試作して実用に耐えるレベルになったので公開したりもしました。

(公開した Nano Banana Pro の Skill で作成したv1.0.0リリース画像。プロンプトは書かず、文脈解釈させて描いて貰った)

そんなこんなですが、体験してきた感覚ベースながら エージェントAIディバイド が生まれつつあるし、今後も広がりそうだなぁと実感しています。

最近は、お客様にAI活用をご支援することもあったりします。あるお客様は、未経験の Visual Studio Code を使い始めて Claude Code を使いこなし、あれよあれよと自社内ツールを幾つも作って効率化するところまで到達してしまわれました。同業の方に比して優位に立てておられるなと感じます。

AI関係は活用ご支援のご依頼も頂いているので、お声がけベースでお請けしていく予定です。こんな感じで、エージェントAIが弊社全体に深く深く入り込んだ1年でした。来年はさらに加速しそうです。

 

プレスリリースを打ちまくった

新しい取り組みとして今年の後半、月2回はプレスリリースを打つという取り組みをやってみました。これも、プレスリリースをAIに書かせる体制を作れたからこそ。下はその一覧ですが、打ちすぎですね😅

日付	内容
2025/12/16	話題の画像生成AI「Nano Banana Pro」をClaude Codeで使えるスキル「ccskill-nanobanana」を公開
2025/12/12	Webサイトアーカイブの espar archive、静的化ファイルをZIP納品する「スナップショットプラン」を新設
2025/11/25	業務用iOS専門メディア運営の実績を活かし、中小企業向けにMDM導入支援プログラム提供開始
2025/11/11	自社のなりすまし被害の実例を公開、非エンジニア向けDMARC解説コラム「ドメインの未来を守る 〜DMARC超入門〜」連載開始
2025/10/28	月額不要！なりすましメール対策に導入急務のDMARC設定を短期集中で p=reject まで完了させるサービス「DMARC導入アドバイザリー」の提供開始
2025/09/30	問い合わせフォーム実装ツールの espar form が、kintone・Googleスプレッドシートと連携する「外部データベース連携機能」の提供を開始
2025/09/09	「サイトが重い、サイトが落ちる」問題に悩むCMSサイトをシステム開発の視点で高速安定稼働に導く「CMS高速化アドバイザリー」のサービス提供を開始！
2025/08/19	WordPressセキュリティ強化の新形態！管理画面への全アクセスを別ドメイン化して攻撃対象面を限りなくゼロに近づける「隠蔽化オプション」の提供開始
2025/07/29	フォームの全角強制ストレスをゼロに！フォーム実装ツールの「espar form」でユーザ入力を自動変換処理をノーコードで追加できるコンバーター機能を搭載
2025/07/15	サーバ構築や証明書作業が不要！ソースコードをzip化して送付するだけでフォーム付き静的サイトを即公開 - espar form で新オプション「フォームホスティング」提供開始
2025/07/01	業界初！静的ページ向けフォームツール「espar form」で独自ドメインDKIM署名を標準機能として無償提供開始

(この表も、AIにプレス一覧ページのURLを渡しただけで全部AIが書いたもの)

数打ちゃ良いというものでもない気がしますが、社内ではPDD(Press-release Driven Development)と呼んでいてw、プレスに合わせて機能を追加していく…というマイルストーン的な意味合いを持たせられたので、良かったなと思っています。

発表時には拡散を狙って、プレスリリースサービスのvaluepressも使っていたのですが、こっちは考えものですね。月額3.5万円で打ち放題というプランがあるのですが、5ヶ月でやめました。

発信者として期待した効果は無く、得られた反応はプレスリリースを打った日に、弊社の問い合わせフォームにどこかの会社から営業連絡が届く という面白い(?)現象ぐらいでした。プレスの内容にもよるのでしょうが、弊社的にはプレスリリースをサービスを使う価値はもうないなぁ、と感じました。

発表記録として自社サイトには一応掲載し、それに言及する形で、ブログや動画で新機能の背景や思いを発信するほうが意味ありますね。記録だけのプレスはAIに書かせれば良いかなと🤖

 

静的Web事業(espar事業)のこと

今年もよく知られた企業様で espar vault や espar form を導入して頂きました。

(バイクや自転車用品のTANAX様の公式サイト)

(リンナイ様の新ショールームのサイト)

最近ニュースで話題になったエンタメのサイトさんとか、著名なVCさんのサイトとかとか公にできないものもあるのですが、WordPressやCMSのしんどい事から解放されたいという制作会社さんきっかけで導入頂けるケースが多いように感じます。静的に作るメリットが徐々に認知されてきたかなと。

今年は espar のブランディングを強化できたのも良かったです。パンフレットも作って頂きました。

(espar のブランディングとパンフレット制作を行なった)

生成AIがCMSの存在に影響を与える?

実は、静的化という文脈でCMSの存在意義に思うことがあります。

多分、WordPressのようなCMSはもう不要になる気がするんですよね。またどこかで書けたら良いなぁと思うんですが、WordPressに限らず汎用的な(?)CMSがいずれいらなくなるんじゃないかなと。エージェントAIにより、サイトもシステムもAIが作る時代が迫っているからです。

その際、PHPやらDBやらフレームワークやらメールサーバやら、色んな要素が絡み合うCMSのような重厚長大なシステムは、エージェントAIフレンドリーじゃないんですよね。不可能ではなさそうですが、かなり大変。静的である(ファイルとして生成される)ことが、エージェントAIとの相性が高く、その恩恵を受けやすいように思えるのです。

これは、静的ページにフォームを埋め込む espar form を開発していて特に実感するところ。

(espar form は静的ページのための JS だけで動くフォーム実装ツール。エージェントAIでの自動生成と相性が良い)

エージェントAIを使ってサイト制作する前提で、Figma で絵を描いた上で「○○事業の企業様のLPです。HTML化して、画像は適当に Nano Banana で生成して、フォームは espar form で実装してね、よろしく」と指示を出すだけで、10分もすれば動作するフォーム付きLPが完成して後は設置するだけ…って世界が見えてきています。これが、WordPress等の従来型CMS前提ではそうもいきません。

また、Claude Code のようなエージェントAIの登場で、顧客の要件のためだけの専用CMSが簡単に作れるようになる可能性も見えてきています。

AI戦略論

CursorがSanityをやめて自前CMSに移行したという話

これはNo SaaS時代に向けた象徴的な転換点だと思っている

Headless CMSはコンテンツエディターとデザイナーが分業するための主要ツールだった

ところがSaaSは顧客に要望される機能をどんどん追加していき、使いにくくなっていく… https://t.co/L9Ms5QbJsO pic.twitter.com/fxTbr7GRTd

— Kenn Ejima (@kenn) December 14, 2025

PHPもDBもCMSもいらなくて、専用のWin/Mac用のUIを持ち、コンテンツ編集結果のHTMLを静的生成して、static なサーバにアップロードしてくれる専用ツール。そんなモノが1,2時間で作れてしまうようになるかも知れませんね。こんなイメージですかね。

(要件に応じたUIを持つ顧客専用CMSツール。HTML生成してアップロード。コンテンツファイルのみクラウドで共有)

汎用性はCMSが持つのではなく、個別CMSを作り出すAI Skillが持つようになり、「このお客様向けのCMSを作って。要件は…」ってAIに投げれば専用ツールができて、それを納品する。そんな世界は遠くない気もします。

結果、静的ページでいかに動的要素を動かすか？が重要になってくる筈で、espar form は幸い問い合わせフォームの分野で相性が良さそうなので、来年はそこに切り込んでいこうかなと思っています。

 

iOS事業のこと

弊社取扱いMDMのBizMobile Go!を導入ご支援する機会が増えてきたこともあり、サービス化して発表しました。

(伴走型 MDM導入支援プログラム のページ)

これまでは、カスタムアプリなど業務用アプリ開発観点でのご支援が多かったのですが、2桁/3桁台数のiPhone/iPad導入で、まだまだ端末管理に悩まれてる企業様が多いことが分かってきました。来年は、そうしたお客様のMDM導入ご支援を強化をしていきたいなと思っている次第です。

先日、この関連でBizMobile Go!のユーザミーティングにご招待頂いたのですが、講演をされた企業の担当者様から「サイトで勉強させて貰ってました」と、懇親会で思いもよらずお話の機会を頂いたりしました。メチャクチャ光栄だなーと。

そのほか身内でもビックリするような展開になるお声がけもあったりして、今年後半は特に、エンタープライズiOS研究所のサイトからご縁を頂くことが続いています。情報発信は本当に大事だなぁと再認識している次第です。

年20個以上投稿してた2020年と違い、今年は投稿1件だけでした😳が「投稿を続けて下さい」という有り難いお声も頂いたりしましたので、来年はもう少し投稿しよかなと思ってます。

(2025年唯一の投稿。色んな方にお話を聞いてまだまだ書けることがあると感じた)

あ、iOSといえば、開発しているブラウザアプリも進めないとですね。いぁ、進んでいるんですけどw

• 10年ぶりの新アプリに向けたブラウザ考察 -コンテンツ重視のUIとiOS26のSafari-

結局、TestFlight 外部テストで沢山の方に使って貰う機会も作れずでした😫 新しいネタを思いついては実装をGOしちゃうので、全然完成しないのは変わらずです😁 いつかお披露目できたら良いですね。

 

そんなこんなで激動ながら楽しい一年でした。来年は、エージェントAI活用をさらに加速、iOS関連も導入ご支援やら自社アプリ開発やら頑張って参ります。2026年もフィードテイラーをどうぞよろしくお願い致します。

WordPress等のCMSを静的化するサービス espar vault の新オプションについてプレスリリースを出しました。プレス本文はこちら。

WordPressセキュリティ強化の新形態！管理画面への全アクセスを別ドメイン化して攻撃対象面を限りなくゼロに近づける「隠蔽化オプション」の提供開始

(展示会で作成した espar vault のリーフレット)

長らく WordPress のセキュリティ分野でビジネスしておりますが、運用中のWordPressサイトを守る一つの理想形に到達できたと思っています。攻撃ができないとはどういうことか、少し技術的なことを紹介してみたいと思います。

 

閲覧系URLに加え、管理系URLも攻撃されないようにする

WordPress サイトをhttp/https層で見ると攻撃される箇所は2つに大別されます。

1. 閲覧系URL
2. 管理系URL

WordPress は1,2の両方でアクセスの度にPHPやDBが動作するため、常に攻撃が成立する可能性が孕んでいます。この状態を「サイト全体が攻撃対象面である」といい、WordPress の構造的な脆弱性です。

そこで、静的化技術を使って、主に1の側、つまり閲覧系URLでは原理的に攻撃が成立しないようにしてセキュリティを強固にするのが espar vault でした。

(静的化したファイルのみを別サーバに設置。PHPもDBも存在せず、攻撃は原則成立しない)

そして今回発表した「隠蔽化オプション」は、主に2の側ですね。管理系で原理的に攻撃を試みさせないようにするものです。「攻撃を成立させない」のではなく「攻撃を試みさせない」という点が、従来の防御手法とは一線を画している部分です。

どういうことか。

 

管理系URLだけを別ドメイン化する

WordPressサイトのURLが https://www.exmple.com/ なら、よく知られる通り管理画面は https://www.example.com/wp-admin/ で、管理系の重要なアクセスは https://www.example.com/wp-admin/〜 以下に集約されています。

ここも狙われるのです。

ですが、もし以下のように、管理画面だけ別ドメインでWordPressを運用できたらどうでしょう？

• https://www.example.com/wp-admin/〜 は原則全て404で応答する
• https://admin.sample.jp/wp-admin/〜 でWordPress管理系のアクセスができるようにする

パッと見は謎に見えますが、要は管理系URLを根っこの部分(ドメイン)から別物にしてしまい、誰にも推測できないURLにするということです。で、関係者は https://www.example.com/wp-admin/ ではなく、管理系専用の https://admin.sample.jp/wp-admin/ という別ドメインからアクセスして、今までと全く同じ操作感で WordPress を操作します。

(WordPressに直接アクセスしなくても良い環境に隠蔽することでWordPressを守る、という発想)

全く関係ない別ドメインなのにそんなことができるのか？

はい。

普通のWebサーバではできないんですよね。Apache でも NGiNX でも不可能です。弊社が独自に開発した ホスト名置換型リバースプロキシ技術 で可能になりました。全く別のドメインにアクセスしているのに、WordPress の管理画面にアクセスができるようになります。

ちょっと不思議ですよね。

そんな管理系アクセス仲介専用サーバをお客様ごとに用意します。これなら、その全く別のドメインを知らない限り誰も管理画面にアクセスできないって理屈です。管理系URLには、攻撃者は攻撃を試みることすらできません。だって管理用URLが全く分からないのですから。

espar vault の静的化と合わせると、前述の攻撃されやすい2大ポイントはこうなります。

1. 閲覧系URL → 静的化した結果が置かれる公開用サーバが応答
2. 管理系URL → 隠蔽化オプションで用意した管理系専用サーバが応答

元々あった www.example.com のCMSサーバには原則、直接アクセスが一切届かなくなるんですね。なので、CMSサーバには全アクセスに対してIP制限とBasic認証を設定でき、より安全になります。

この構成で、攻撃するのは事実上不可能と言えるほどにWordPress サイトは強固になります。閲覧系への存在しないURLや管理系URLは全て404ですし、別に用意する管理系URLは推測不可能であると。

もちろん例外はあります。これを我々は「動的要素」と呼んでいます。問い合わせフォームから「送信」ボタンを押す瞬間とか、どうしてもその瞬間にPHPが動作しなければいけないURLパスってのがあったりします。ここは、リバースプロキシ技術を使ってWordPress本体にアクセスが届くようにします。

(本当に必要なURLパスのパターンでのみ通過するように設定するので、簡易の手動設定WAFみたいなもの)

そこが攻撃されないよう、やっぱり全て静的化できたほうがいい。だから静的化したページ上で JavaScript で動作する espar from を開発したという経緯があります。

このようにわずかな例外が生じる場合はあるものの、ほぼほぼ攻撃不可能な WordPress になることがご理解いただけるかと思います。

 

セキュリティで最も大切で有効な考え方

セキュリティに絶対はありません。

だから、何かを守りたい時、最も大切な考え方は、deny all, each allow の原則を貫くことです。まずは全てをいったん拒否(deny)し、個別に許可(allow)する。

家の玄関とか、まさにそうですよね。すべてをいったん拒否(鍵付き扉を設置)し、個別に許可(家族にだけ鍵を渡す)します。飛行機や万博のゲートもそうです。いったん拒否(ゲートでせき止め)し、個別に許可(持ち物検査して通す)します。

もちろん絶対はないですが、まず入り口の初手で「現実的に攻撃は不可」と言える状態までセキュリティをいっきに引き上げるのです。細かいことはその後です。このやり方が一番安全であることは、現実世界を見れば自明の理でしょう。

CMSやWebシステムの多くは、残念ながらこれができていません。allow all, each deny なんですよね。メールだってそうです。まず全部受け入れちゃう。そこから守ろうとする。そりゃ漏れますよ。

システムやメールの特性上、どうしても deny all を初手に持ってこれない場合もあるんですけどね。でも、情報発信が主体の CMS サイトならこれが比較的容易です。まず全部拒否(404)することにし、存在するページのURLだけ応答する、以上。というわけです。

まぁ、究極は「使わない」ですけど。ぶっちゃけるとWordPressをはじめCMSを使わないことです😁 SSGを使うか手書きで書いてHTMLファイルを設置するだけが一番安全です。でもそれはまだまだ現実的ではない。だから deny all, each allow で守りを固めてから使うべき、と弊社では考えています。

 

ということで、新たにリリースした espar vault の「隠蔽化オプション」についての解説でした。WordPress の使いやすさはそのままに、セキュリティを高めたいという場合に是非ご検討ください。「静的化」が前提になっているので、理論上の最高速度にスピードUPするというメリットもついてきて、一挙両得です😁

本日2025年7月7日、弊社フィードテイラーは創業から丸19年を迎えました。

もうすぐ20年です。ここまで続けられているのも、ひとえに日頃からお付き合いを頂いているお客様やパートナーの皆さんや社内メンバー、仲良くして頂いてる経営者仲間の皆さんのおかげです。心より感謝申し上げます。ありがとうございます。

恒例ではありますが、近況のご報告などを。

 

Claude Code の『JOIN』

この1年の間で最も大きな弊社変化の一つが、5月下旬に登場したClaude Codeの導入です。

2024年後半から Cursor、GitHub Copilot、Cline など色々使ってきましたが、それらを遥かに凌ぐタスク処理能力で業界が騒然としましたね。弊社でも早々に評価して、6月より社用標準ツールとして位置付けました。

が、正直 Claude Code の採用は、ツールの導入というより 組織に新たなメンバーとして AI が『JOIN』した という感覚が近いです。しかも1人ではなくN人で、使いこなし度合いによってNは2にも5にも10にもなるという…。エンジニアにとっては部下エンジニアがついたと言えますし、雑務担当な僕にとっては総務・企画・広報メンバーとして実務をこなす部下が増えたような感じです。

(ある業務効率化のツールを作らせている様子。機能追加を依頼するとガンガン実装→テスト→修正してくれる)

タスクを投げたら、Claude Code から「これやって良いですか？」と質問されたり、「完了しました」と通知が来るまで基本は放置、その間、自分は他のことをやる…みたいな仕事スタイルが確立しつつあります。

複数の Claude Code インスタンスに別のプロジェクトのタスクを同時並行で走らせたり、同じプロジェクト内で複数の Claude Code に同じことをやらせて一番良いものを選んであとは捨てる…みたいなAIメンバーが複数人いる前提の仕事スタイルも模索しています。

後発のGoogle製 Gemini CLI も併せて評価していて、こちらは開発業務というよりもドキュメント作成系の人員としてのAI。執筆のあと人間の確認と微調整を経たあと、更新作業を勝手にやってくれるみたいな。言っても5月下旬からの動きなので、まだ理想には程遠いですが、体制づくりを進めています。

今後、「チャット型AIのサイトを開いて、プロンプト打って、出力をコピペして」といったことの必要ない、AIが自走できる環境づくりが本当に大事になりそうです。

従業員/メンバーとしてAIを育てよう。組織のAI化を進めていこう。

そう思えるほどに、たった1ヶ月のうちに世界観が変わってしまいました。そんな激動の波に乗りながらにはなるものの、基本的には従来と変わらず静的Web事業とiOS事業を進める1年でした。

 

静的Web事業 espar

発信の強化

色々やった1年でした。リブランディングして発信を強化したり、静的サイト向けフォーム実装ツール「espar form」の専用サイトを作ったり、展示会に出展したりしました。

どれも過去にはやったことのない取り組みばかりでこの1年は特別だったのですが、特に展示会出展はリアルなもの作りで系統も違ったので、とても面白かったです。

(おおよそITらしくないブースに仕上がった。espar form だけでなく espar vault も知って頂く機会に)

アイテムの制作には、お馴染みメタ・グラマーさんにお手伝いを頂きました。リーフレットだけでなく背面パネルに掛ける高さ3mの垂れ幕やテーブルクロスまでお願いしました。イラストはほんわか系の女の子イラストが特徴のいとうみゆきさん。

(esparのブランドコンセプトにあわせてリーフレット用のイラストを描いて頂いた)

手に取れるモノ作りが本当に久しぶりで3社(者)での共同制作は楽しい経験でした。メタ・グラマーさんには制作過程で Blender を使ったシミュレーション(!!😳)をして頂くなど、かなり最先端な作り方も体験できました。

(今や定番の3DツールBlenderで展示ブースの完成系をレンダリングして頂いた。やはり圧倒的にイメージしやすい)

イベント当日の集客は想像してたより少し控えめだったのですが、色んな方にCMS静的化のメリットや、PHPレスな問い合わせフォームのメリットをご説明できたので良かったです。同じように出展されていた制作会社やクリエイターの方々と新たな繋がりが生まれたのも大きな収穫でした。

機能強化と実績

実はこの1年の間に、実質半年近くかけて espar のインフラを刷新しました。Arm版EC2インスタンスを実戦投入したり、Docker もフル活用。そんなこんなで19年目の1年間は espar にとって「目に見えない部分の強化」の年となりました。

が、そのかいあって、機能追加もし易くなったのです。

直近では espar form を機能強化してプレスリリースを発信。問い合わせフォームから送信されるメールに「独自ドメインDKIM署名する」というWeb関係者でも詳細をご存知ない方が意外に多い技術です。

各社の迷惑メール対策強化もあいまって今後はDMARCというキーワードと共に各社Webサイトは対応が不可避になるだろう…と、先手を打っての発表を行った次第です。

(サイト更新含め6割程度がClaude Code担当。プレスリリースサービスへの登録まで全部丸投げできる体制づくりを目指す)

色々と発信してきた成果なのか、新規導入のお話もちょくちょく頂いており、直近では名古屋の住設メーカーのリンナイ様に、WAFを代替するセキュリティ機構として espar vault を導入頂きました。

(理屈上は第三者がCMSを攻撃不可な構成にできる espar vault を評価頂いた)

やっぱり発信したら何かが動き出すものですね。次の1年も発信を継続してまいります。

 

iOS事業

この1年、ブログで少しずつご紹介しながらですが新しいブラウザアプリの開発を粛々と続けてます。

• 10年ぶりの新アプリに向けたブラウザ考察 -スクリーンは誰のものか-
• 10年ぶりの新アプリに向けたブラウザ考察 -Adネットワークに占拠されたユーザのスクリーンを取り戻す-
• 10年ぶりの新アプリに向けたブラウザ考察 -コンテンツ重視のUIとiOS26のSafari-

@hitonomichiさんに協力して貰って、社内の @t0shiya も巻き込んで、デザイン面ではいよいよメタ・グラマーの @kasydmk さんも巻き込んで、開発開始から6年目に突入ですw もはや「サグラダアプリ」と化してますが😁

(コンテンツを邪魔せず、必要な時だけ現れる新しいブラウザUI「バーデッキ」。図らずもiOS26のLiquid Glass に少し似ていた)

まだまだやりたいことの3〜4割しかできていませんが(次々作りたいものを思いつく自分が悪い😅)、普段使いできるかも状態にはなってきたように思います。ので、身近な人からお声がけして、ちょっとしたお披露目会(?)みたいなこともやってみたりして、TestFlightでの配信範囲を広げよかなと思ってます。お声がけさせて頂くみなさま、宜しければお付き合い下さい🙇‍♂️

一方、B2BのエンタープライズiOS事業は投下するリソースを減らしていて、ブログの投稿頻度もフェードアウト。2025年に入ってからは何と1件だけですw

正直なところ、ぼちぼち業務用iOS関連の知見を発信するという役割は終えたかもなぁと感じています。出し尽くしたわけではないのですが、そこそこ基本知識の啓蒙には貢献できたのではないかなぁという妙な達成感と、Apple も以前よりは相当しっかり情報発信してくれるようになっているという事情もあります。(やっぱりAppleから学ぶのが一番です😊)

ただ相変わらずコンサルティングのご相談は継続的に頂いてますので、今後は発信よりも個別企業様にあわせたご支援に軸足を移していこうかと思っています。業務用のiOS端末活用やアプリ開発のガイドライン作り等で悩まれてる企業様がおられましたら是非お声がけください。

 

ということで、長くなりましたが、この1年も各事業で少し歩みを進めることができました。さて20年目はどんな年になるでしょうか。AIを組織や自社サービスにもっと取り込んで、これまで以上に良い意味で変な会社にしていきたいと思います。

今後ともフィードテイラーを、どうぞよろしくお願いいたします。

WWDC2025でiOS26が発表され、OS全体のデザインが Liquid Glass という新たなコンセプトで刷新されることが明らかになりました。

オッと思ったのが、Safari のUIが紹介された時。以下が新しいSafariです。ステータスバーはほぼ透過して主張が弱くなり、画面最下部には表示中サイトのドメインが表示されています。

(Apple公式iOS26のページから)

広々としてますね。Apple は Liquid Glass というデザインを「コンテンツに一段と集中できるように」することを目的として開発したようでした。

 

コンテンツに没入できるブラウザUIが抱えるジレンマ

開発中のブラウザアプリでは「コンテンツへの集中」を重視しています。過去にも幾つか投稿しました。

• 10年ぶりの新アプリに向けたブラウザ考察 -スクリーンは誰のものか-
• 10年ぶりの新アプリに向けたブラウザ考察 -Adネットワークに占拠されたユーザのスクリーンを取り戻す-

ブラウザUIは極力排除し、フルスクリーンでコンテンツが見れるべきであると。

それはまぁそうなのですが、実はUIを無くすと「他のサイトに移動できないよね？」「戻ったり進んだりは？」など、ブラウザが備えるべきUIをどうするか問題にぶち当たることになります。

戻るなどの操作はジェスチャーで回避できますが、全部が全部ジェスチャーというわけにはいきません。ブラウジングの基本操作とかぶってしまう可能性を考えれば、ジェスチャーの操作もそれほど多用できるものではないのです。

(と言いつつ多数のジェスチャーを定義できるようになってはいるのですがw)

ブラウザ開発でコンテンツを重視しようとすると、「便利にする→UIがいる→コンテンツを阻害する」というループというかジレンマは不可避ですね。ブラウザアプリの宿命なのかも…と、作っては壊しを繰り返して行き着いた先で、開発中のブラウザでは一つの解を見出していました。

それが以下の画面。

(画面最下部にツールバー。iPhoneミラーツールのBezelでキャプチャ)

iOS26のSafariと少し似てませんか？😁

元より既存のタブ型UIでは限界があると感じていました。なので、フローティング＆ブラーで存在感を無くしつつ、ブラウジング中には極力表示されず、それでいて使いたい時には表示されるようなブラウザUI実装に舵を切っていたんですね。

これがいみじくも、今回発表された新しい Safari に似ていなくもない形だっだと…。Appleはもう何年も前から Liquid Glass のデザインに着地していた筈ですが、Apple と近しいことを考えていたのかも知れないと思うと普通に嬉しいですよね😊

で、このUI、ちゃんと動きます。現状こんな感じ。

(ブラー効果の程度も設定できる。存在感は極少に。積極的に消えてくれて、使いたい時にまた現れる)

発案は昨年。実装を始めたのが年始頃。形になって TestFlight で先月から配信して、意外に使い易いかもねー良いですねー、なんて話をしていたのでした。ユーザは現在4人だけなのですけどね😅 (サーバ担当の@t0shiya、iOSアプリは@hitonomichiさん, ロゴ関係でメタ・グラマーの@kasydmkさん、そしてPdMである僕の4人)

メンバー全員が、今回の WWDC2025 動画を見て思わず笑ってしまったのでした。

そんな新しいブラウザUIを僕らは バーデッキ と呼んです。

 

バーデッキのご紹介

バー(Bar)が並ぶところ、という意味でバーデッキ(BarDeck)です。

現Safariを含め多くのブラウザアプリで邪魔に感じてたのは、ツールバーだけではありません。ステータスバーもアドレスバーも同様。コンテンツをめいいっぱい楽しもうとすると不要に思える「バー」が多いのです。必要なものではあるけど画面に居座って欲しくないのですよね。

(以前の投稿で言及した、ブラウザUIの画面占有率の考察画像。画面全体の20%を占めている)

それらのバーを一箇所に集約し、必要なタイミングで切り替えられるようにしてみたというわけです。こんな感じで動きます。

(見易さのためにDark系ブラーに変更した(これも設定から変更できる)。左右スワイプでバーを切り替える)

常にツールボタンが見えて欲しいわけじゃないし、時間やバッテリーのステータスもいつも見えてなくて別に良い。URLだってそうです。なので、手元でスッスッと左右スワイプして、見たいもの使いたいものを切り替えられたら便利かなと。表示領域を共有するので画面も無駄に占有しなくなります。

実際にUI検証した評価は、画面占有率を最小化しつつ必要十分なブラウザUIも提供するという二律背反な要件を両立させるちょうど良い着地点かなぁ…という感じ。なので、これを基本路線としました。

面白いのは、このバーデッキというUIをブラウザUI(バー)の入れ物だと捉えると、色んなアイディアが湧いてきたこと。元はと言えばタブがフローティングになっただけですのにね。

• 「ツールバーを何個も並べれても良いのでは？」
• 「ならばツールバーに色んな便利ボタンがあっても良いのでは？」
• 「ステータスバー・ツールバー・アドレスバー以外のバーも考えられるのでは？」

などなど。そうして生まれたのはこんな設定画面です。

(ツールバーが2つあっても良い。ツールバーが複数置けるなら色んなブラウズ支援ボタンがあっても良い)

実際に動き出すと、発想がさらに広がるもんですね。発散するとも言いますが。

まぁこんな感じで、作っては壊し、ハマれば、そこに新たなアイディアが生まれてまたやることが増えていく…を繰り返すのでいつまで経っても完成しないというわけです(笑)

iOS26 の Liquid Glass というデザインとそれに伴う基本UIの刷新をうけ、ご紹介したこのUIもまた調整余地が生まれる可能性もあります。本アプリが iOS26 以前にリリースされる筈もありませんし。やはり永遠のベータなのかも知れません😅

 

ということで、今回は開発中ブラウザアプリの個性的なUIバーデッキについてのご紹介でした。まだまだ気になることもありながら常用できるかも？🤔な状態になってきた気もしてまして、TestFlight の配信範囲を徐々に広げていけると良いなーなんてこともボチボチ考えています。

気がつけば2025年も半分が過ぎようとしています。ここ最近は「静的Web」事業の強化を掲げて、さまざまな新しい取り組みを進めてきました。

• 静的化サービスのesparをリブランディングしました
• 6月開催の「この街のクリエイター博覧会2025」に出展します
• オンラインマニュアルの全面刷新
  • espar vault オンラインマニュアル
  • espar form オンラインマニュアル

これに加えて、各サービスの専用サイトの立ち上げも進めていました。この度、PHPレスな静的ページ向けフォーム実装ツールである espar form の公式サイトがオープンしましたのでご紹介いたします。

(問い合わせフォームにはもちろん espar form を採用。全ページでCMSやPHPは使っていません)

これまでは、弊社サイト内の一部で簡単にサービスをご紹介する程度でした。

が、espa form をなぜ作ったのか、どんな機能があるのか、今後の開発計画やJavaScriptで実現する仕組みや技術情報など、広く深く発信していくためには専用サイトが必要だと感じていたのです。

そこでパートナーの@koronpoさんにゼロベースで LP+α って感じの構成でデザイン面を含めて制作して頂きました。

2025年らしく、実装に際しては

• 独自ビルドシステム開発
• サーバ転送プログラム開発
• 既存コンテンツからの変換や文章作成

などで Agent AI を使ってます。画像には Midjourney。

AI にすべてを丸投げするのではなく、手間のかかるタスクをAIが解釈しやすい粒度に分解して依頼する形で活用しました。サイト制作分野におけるAI活用のポイントも掴むことができたと感じています。

(カテゴライズして特徴や機能を網羅的に紹介。開発ロードマップも掲載)

今回、サイト作りを通じて自社製品を見つめる機会にもなり、思った以上に「機能豊富なツールに仕上がってるなぁ」とか「名だたる企業様に使って頂いているなぁ」等々の気づきが得られました。

(導入事例ページを作り込んで、改めて社内でビックリするという…😅)

espar form は、Webサイト制作に関わる事業者の皆さまに、制作スピードの向上やフォーム品質の向上、メール運用の手間からの解放など、他のツールにはない多くのメリットをご提供できるものと自負しています。

(PHPやサーバ周りのエンジニアが不在でも高機能なメールフォームを作れるのが大きな特徴)

短時間ではご紹介しきれない特徴や機能がありますので、ご興味をお持ち頂けましたらサイトをご覧下さい。オンラインマニュアルには、実装イメージ等の細かい記載もありますので併せてどうぞ。

 

ということで espar form サイトのご紹介でした。今後とも「静的Web」ブランドの espar と、フォーム実装ツールの espar form をどうぞよろしくお願いいたします。

タイミング良く(?)、来たる2025年6月6,7日に開催される「この街のクリエイター博覧会2025」で espar form を展示させて頂く予定です。詳しく聞いてみたいという方がいらっしゃればよろしければお越し下さい。

来たる6月6,7日の2日にわたって開催される**この街のクリエイター博覧会2025**に出展いたします。

(メビックさん主催。毎年開催だが、今年は関西万博に合わせてスペシャルバージョンとのこと)

Web業界を含むいわゆる大阪のクリエイター達、法人/個人で合計約200組が、自社の事業やサービスを発信します。会場は堺筋本町のマイドーム大阪で、2フロアを借り切るそうなので結構な規模ですね。

その中で幅1.5m程度の小ブースを出させて貰うことになりました。ブースは、会場3階のC-55です。最近の展示会は出展者ごとに専用PRページも作らせて貰えるそうです。便利な時代になりましたね😳

(ブースはよくあるコの字ではなく背面パネルだけのシンプルなもの。連結せず1区画だけなので、かなりコンパクト)

会期中は、先日リブランディグしたての「静的Web」ブランドの espar から、問い合わせフォームの実装ツール espar form をご紹介予定です。Web関係者の方に向けて、問い合わせフォームにPHP使って苦労するのやめませんか？もっと楽しませんか？ というメッセージをお伝えしたいと思います。

また、せっかくですので同じ espar ブランドのCMS静的化サービス espar vault も軽くご紹介しようかなと。ただ、後述の通り、製品を売り込むようなビジネスビジネスしたブースにはしない予定です。

ブースは決して大きくないし、いかにも展示会っぽい普通のブースは余り面白くありません。ちなみに2017年にインテックス大阪で出展した時は、以下の写真のような感じでした。

(とりあえず置けるものを手当たり次第に置いている感じだった)

まぁ、ベーシックにやるとこうなりますよね😅

同じことをしても面白くなく、極小ブースでいかに目立つかを工夫しようかと考えを練りまして。おおよそIT企業らしくない、余り過去に例をみない(当社比)ことをやってみることにしました。

ブースをキャンバスに見立て、サービスの世界観で彩ってみようと。

(generated by Midjourney v7)

弊社 espar ブランドは、Web制作や運用の苦労からの「解放」を目指してます。サイト構築や運用でそんなに苦しまなくても良いですよ、静的Webの技術で楽になれるんですよと。コンテンツの制作だけに専念できたほうが幸せですよね、と。

その世界観を表現してみることにしました。さて、どうなるでしょうか☺️

 

ってなわけで、出展のお知らせでした。6/6,7 の2日間の開催で、場所はマイドーム大阪。僕は espar ブランドのプロダクトマネージャーとして終日ブースにいる予定ですので、よろしければ3階C-55まで遊びに来てやって下さい🙇‍♂️

CMSを静的化する事業 espar を始めて7年が経ちました。

派生サービスの espar form や espar archive も生まれ、静的Webのフィードテイラーさん という見方をして頂くようにもなりました。お世話になっているお客様や関係者の皆様に御礼申し上げます🙇‍♂️

さて、気がつけば弊社の事業は「業務用iOS」と「静的Web」の二本立てとなりまして、特にここ数年は前者の業務用iOS分野にリソースを割いてきました。本年、2025年は後者の「静的Web」をもっと広める活動やサービスの機能拡充など、「静的Web」事業にリソースを割く予定にしています。

そこでこれを機に「静的Web」事業のサービスをリブランディングすることにしました。今これだけの静的Web関連サービスがあるのですが、

(esparブランドの既存製品)

ロゴを刷新し、一部のサービスの呼称を変更します。

(メタ・グラマーさんにご協力頂いた。「すぐに導入できる」という特徴をスピード感ある雰囲気で表現)

espar という名称を「静的Web技術のブランド」として格上げし、静的Webに関するいろんなサービスをぶら下げる格好にします。

これに伴い、元々「espar」と呼んでいた大元のCMS静的化サービスを、今後は espar vault (エスパーボルト) と呼ぶこととさせて頂きます。関係者の皆様におかれましては、機能や価格等に変化はありませんのでご安心下さい。espar form や espar archive の呼称はそのままでロゴが変わるのみです。

今後、徐々に営業資料、紹介画面、契約書面、マニュアル、公式サイト上の表記…等々を変えていく予定です。

 

リブランディングの理由

espar を、静的Webの技術ブランドとして位置付ける理由は2つありました。

1. 派生で生まれたサービス「espar form」を単独で採用頂くことが増えた
2. 他にも「静的Web」の切り口で作りたいサービスがある

サービス構造を少し整理したかったのですね。加えて、「静的Web」のメリットをもっと啓蒙したいという思いも強くなり、事業開始時に作った造語 espar をそのまま中心に据えることにしました。

 

espar から espar vault へ

「静的Web」事業の基点だったCMS静的化サービスは、「espar」ブランドの「espar vault」というサービスに位置付けられることになります。

vault とは英語で「金庫」や「貯蔵庫」を意味する言葉。大事なものを中に入れて守る役割を担うものを vault と呼び、セキュリティ関連の機能やサービスに用語として使われることが結構あります。

(パスワード管理ソフト1Passwordでは暗号化されたパスワード保存箇所を vault と呼ぶ)

弊社サービスを導入頂くと、CMSを静的化して、弊社公開サーバにホスティングして、全アクセスの矢面に立つ…という構図になるので、中に入って頂いて守る、まさに vault という役回りなんですよね。

(DNSを変えるのでCMSサーバには原則アクセスが届かなくなり、インターネットの世界から隠蔽される)

また日本語圏的発想ですが、 vault の発音はカタカナ英語的には「ボルト」と表記され、bolt という英単語を連想させます。bolt は「雷」を意味する言葉で、スピードや速さをイメージさせますね。静的化はサイト応答速度にも寄与するので、この意味も込められると解釈した次第です。

 

ということで、リブランディングについてのお知らせでした。

今後は、CMS静的化サービスの「espar vault」、フォーム実装ツールの「espar form」、サイトアーカイブサービスの「espar archive」、この3つで静的Web事業を展開してまいります。

静的Webに関してやりたいことは沢山あって、また何か他の espar なんとか…が生まれるかも知れません。ご期待ください。今後とも弊社の静的Web事業をよろしくお願い申し上げます🙇‍♂️

今年は12/26(木)に最終営業日を迎えました。(27日以降にご連絡頂いたお客様には少しお待たせしてしまいますがスミマセン🙇‍♂️)

無事に今年も年を越せそうで、弊社に関わって頂いた皆様に改めて感謝申し上げます。ありがとうございました。例年通りですが、1年の振り返りをしてみようと思います。

(今年の忘年会は、しゃぶしゃぶで手配したつもりがすき焼きに…)

 

自社アプリ事業

Webブラウザを作っています。ステルスでやってて5年目です。今年は初めてその概要をブログにポストしました。(結局2つしかpostできず…)

• 10年ぶりの新アプリに向けたブラウザ考察 -スクリーンは誰のものか-
• 10年ぶりの新アプリに向けたブラウザ考察 -Adネットワークに占拠されたユーザのスクリーンを取り戻す-

ネイティブ実装を @hitonomichi さんに、サーバサイドは社内の @t0shiya で、PdM(プロダクトマネージャー)は僕ってな3人体制。今年も、あーでもないこーでもないと言いながらスクラップ&ビルドを繰り返しました。

(今年TestFlightで内部テスト配信したビルドは38個。そこそこ飛ばしてますね)

例年と違うのは、TestFlightで遂に！外部テスト配信を開始したことです。いよいよ開発部隊の外へですね。…とは言っても、お馴染のメタ・グラマーの@kasydmkさんお一人だけなのですけど。デザイン面のご協力を頂くべく使って頂いてます。

やりたいことがまだまだ山のようにあるので、来年もリリースに至ることはないですが、も少しTestFlight配信の範囲を広げられると良いなと思います😊

 

エンタープライズiOS事業

業務用のiOSアプリ開発のご支援や運用支援の事業です。

春先にとある上場企業様を1年近くご支援してきたプロジェクトが区切りを迎えました。新たに継続コンサルティングをさせて頂く企業様もあったりでボチボチと。相変わらず積極的な営業はしていません。来年もご依頼やご紹介があれば…という完全受け身姿勢の予定です。

(業務用iOSアプリで困った時の相談窓口的な感じ)

一方、来年コンテンツの発信では新しい取り組みを始めます。2020年に登壇させて貰った時の記録動画がYouTubeの iOSDC Japan 公式チャンネルで結構な再生数を弾き出してるのですが(歴代4位)、

さすがに4年以上が経って情報も古くなってきてまして。App Store Connect も Xcode も随分変わってきましたし、ここいらで一度、改めて業務用iOSアプリを概観できるコンテンツをアップデートしておきたいと思っています。

(資料の作り直しをしている)

ただ、同じネタのupdate版で再び講演…ってわけにはいきませんので、自社で YouTube から配信するとか、教材コンテンツとして提供するとかとかでしょうか。来年何らかの形で発表致します。

 

静的Web事業

CMSサイトを静的化する espar と、PHP不要のフォーム実装ツール espar form を中心に、静的Web事業を続けています。

こちらの事業もほとんど営業らしい営業をしてないのですが、ありがたいことにネット検索やご紹介でお引き合いを頂くこともあり新規導入がポツりポツり…という感じでした。劇的な成長はしてませんが、静かに広がってると実感します😊

特に変わった出来事といえば、Drupal のサイトで espar を導入して頂いたことですね。普段は WordPress が多いですが、どんなCMSでも静的化できる強みが活かされた格好です。これは類似するサービスに無い特徴ですね。

(光学系のB2B製品を開発販売されている企業様。セキュリティ強化でDrupalの静的化)

あと珍しいところでは学校様です。ある高校様に espar form を新規で導入頂きました。

(かの石川啄木の母校らしい私立高校様の問い合せフォームでご利用頂いている)

ここ数年、espar も espar form も機能的には大きな変化なく淡々と…という感じだったのですが、2025年は連携や新規機能も含めて少し面白い動きができるかなと。都度プレスを打ったりして、発表も色々していきたいと思います。

 

そんなわけでアッという間に過ぎた2024年でした。2025年もフィードテイラーをどうぞよろしくお願い致します。

今、ブラウザだけどブラウザっぽくないブラウザアプリを開発していて、開発するに至った背景や思いみたいなものを「考察」として書いています。今回はその第2回。前回と前々回は以下です。

• 設立から18年を迎えました
• 10年ぶりの新アプリに向けたブラウザ考察 -スクリーンは誰のものか-

前投稿では、スマホでWebを見る時に2つのモノを邪魔に感じると書きました。

1. Adネットワークの広告
2. ブラウザやOSの標準UI

このうちまず2.を無くしたい、2.の表示/非表示をコントロールしたい、…というのが前回投稿の主張でした。以下はその考えで試作したアプリの様子です。

ブラウザアプリ使用中に標準UIが一切出てこなくなると「視界が開けたなぁ世界は広いなぁ」と実感できます。我々はずっと、狭窄したスクリーンで**Webをのぞき見る**というユーザ体験に慣らされてきたのかも知れない...、Webブラウズ中に不要な標準UIを無くしてみて初めてそう思いました。

さて、スクリーンの広さを阻害する存在…としてもう一つ気になるのは、Adネットワーク広告です。本稿では、そのAdネットワーク広告について、スクリーンを占有する存在という捉え方で考察してみたいと思います。(昨今何かと問題になっている広告内容の是非については言及しません)

 

ユーザのスクリーンを占拠するもう一つの要素

例を見るのが分かり易いので、あるサイトのページを例示します。皆さんご存知のレシピサイトですね。前回同様にWebコンテンツそのものではない領域に色を乗せています。青色部分がiOSやSafariの標準UI、赤色部分がAdネットワーク広告です。

画面下部の赤色部分がお馴染のAdSense広告です。これ単体でも結構なスクリーン領域を占めており、占有率は9.6%で約1割。これは、ユーザがレシピサイトでレシピを見ようとしているのに、スクリーンの9.6%はその目的のために使えていないことを意味します。

AdSenseだけではありません。標準UIの青色部分もコンテンツ閲覧には関係がない箇所です。前回投稿で解説しましたが、この部分はスクリーンの約2割ですので、合計するとスクリーンの約3割がユーザの見ようとするWebコンテンツではないもので占められていることになります。結構大きいですね。

そしてスクロールすると状況は悪化します。

Safariの標準UIが少し占有率を下げるものの(最下部)、追加のAdSense広告(画面中央)が現れてきます。その占有率は意外に大きく単体で27%。ずっと居座ってる前述の画面下部の広告と併せると、AdSense合計スクリーン占有率が37.5%の約4割となります。AdSenseだけで…です。

少し控えめになったとはいえ、青色部分のiOSやSafariの標準UIも残ってますから(約13%)、合計するとスクリーンの約50%がWebコンテンツと無関係なもので埋まってしまうのです。ユーザはWebブラウザアプリを使っているのに、Webコンテンツのためにスクリーンの半分しか使えてないことになります。

あと忘れてならないのは、画面中央AdSense広告の周囲グレー色部分です。実はHTMLを解析すると広告領域として定義されていることが分かります。ですので、下図のように捉えることもできます。

こうするとAdSense広告だけで合計53.3%となり、標準UIを合算して約66%。四捨五入すると約7割です。なんとスクリーンの約7割がWebコンテンツと無関係なもので埋まっている状態となります。

まぁ、スクロールすると真ん中のAdSense領域はスクリーン外に出て行きますから、常に7割が占拠されているわけではないのですけどね。

そうだとしても、Adネットワークも標準UIもユーザのスクリーンを何だと思っているんだ？…と疑問が湧いてきます。電気代返して…。特にAdネットワークは割合を計算すると本当に酷いです。最大で53.3%ですから。過半数越え。もう少し遠慮して頂きたい😤

そう考えると、昨今話題に事欠かない広告ブロッカーについて考えたくなるというものです。

 

ユーザのスクリーンを取り戻す

僕は広告ブロッカー賛成派で、随分前から使ってます。が、Adネットワーク広告がスクリーンを侵しているという観点で言うと、現存の広告ブロッカーでは完全な解決に至れてないなと考えています。

以下に広告ブロッカー使用前後の比較画像を作ってみました。左は before、右は after です。

(標準のSafariで表示。広告ブロッカーには有名な280blockerを使った)

画面下部のフローティングなAdSenseは消えている一方で、画面中央にあったAdSenseは内容こそ非表示になっているものの、領域はそのままです。これではユーザのスクリーンがAdネットワーク広告に侵されたままの状態は変わりません。

広告ブロック機能を搭載している Arc や Brave のようなブラウザアプリでも同様です。

(左がArc、右が Brave。いずれも広告ブロッカー機能を標準搭載したブラウザアプリ)

こうではなく、広告表示用の領域ごと非表示にして欲しいと思うのです。DOM要素まるごと。上図の例で言うとグレーの領域全部です。

まぁサイトによっては領域まるごと非表示になってくれる場合もあるのですが、そうならない上図のような例が多い印象です。これは、サイトによってAdネットワーク広告の埋め込み方が色々異なるからですね。

そして、前回投稿から繰り返し書いているように画面の上下にある標準UIも非表示になって欲しいわけです。スクリーン全てをWebコンテンツのために使いたいですから。

『私のスクリーンを返して…』

これが課題認識であり、従って現存のブロッカーでは正直不満なのです。基本、全部丸ごと非表示にできるようにしませんか…と。前回投稿で標準UIを原則非表示にしたのと同じですね。Webコンテンツを見たいのだから、Webコンテンツ以外は何であれ見えて欲しくない。

この考えを反映して実装すると、こうなります。

広告用だった領域がまるごと非表示になりました。そして標準UIも表示されていません。なんと広々としたことでしょう😊 せいぜいレシピの手順2,3ぐらいまでの表示だったものが、グラタンが完成する手順9まで表示できています。

Webコンテンツを見るってこういうことじゃないでしょうかね。

無論、これをサーバ側で行う実装は著作権的に完全アウトです。コンテンツ改変と解されることをして再配信することになるわけですから(公衆送信権や同一性保持権等の侵害)。しかし、クライアント側でユーザが自分の利用する範囲において非表示にするなら、既存の広告ブロッカーやブラウザアプリと何も変わったところはありません。

ちょっと技術的なことを書くと、iOSではiOS11からOSの標準機能としてブロック機能が搭載されました。具体的には WKWebView を内蔵ブラウザとし WKContentRuleListStore のインスタンスにルールセットを指定してバインドすれば、内蔵ブラウザ部分が様々なものを無効化・非表示化することができるようになっています。多くのブロック機能搭載ブラウザがこれらを使って実装されています。

(280blockerのようなSafariに機能させるブロッカーはextensionで実装する。上記はその公式ドキュメント)

開発中のアプリでももちろん同じ仕組み WKContentRuleListStore を使っています。AppleがiOSに標準搭載しているブロック機能を使用しているだけ。少し違うところを書くなら、ルールセットの与え方を若干工夫している点でしょうか。それによりAdネットワーク広告の内容だけでなく、その領域もほぼ確実に非表示にできる機構を備えています。以下は実際に動作する様子を示したキャプチャ動画です。

(サーバ側の実装で改変している訳ではなく、オリジナルのhtmlを受信したアプリ側がiOS標準機能で非表示化する)

スクリーン全体でWebコンテンツを表示できていますよね。余計なものが一切ありません。なお、見るWebサイトを切り替える方法は、これまでの投稿で未言及のため上記動画では省略してますが、またの機会に紹介できればと😊(見ようとするWebサイトを切り替える仕組みを別途用意するつもりです)

ところで、ご存知の方も多いと思いますが2024年9月にリリースされたiOS18では、広告表示用の領域ごと非表示にすることが可能になりました。だからサイト毎に非表示に出来ることに目新しさはもう無くなってしまいました。以下、実際に使っている iOS18/Safari の動画です。

(都度、ページごと広告ごとに何度もタップする必要があるだけでなく、リロードで復活してしまう。常用は現実的でない)

依然として標準UIは表示され続けているため、スクリーン全体でWebコンテンツを楽しめるわけではありません。これはこれでアリだと思いますが、やっぱり標準UIは消えて欲しい🙄 そしてAdネットワーク広告は領域ごと非表示にしたい。

スクリーン全体にWebコンテンツを表示させたいのです。

そんなユーザ体験を作ることができたら、iOS・ブラウザアプリ・Adネットワーク広告が散々削ってきた我々ユーザのスクリーンを取り戻せると思うんですね。

 

だいぶ長くなってので一度このへんで区切りとしたいと思います。

実はAdネットワーク広告については論じたいことが沢山あります。「広告があるから無償で見れてるんだぞ？」とかとかですね。一応、自分なりの答えを持って開発をGOしている次第なので、そのあたりもどこかで書いてみようと思います。今回の投稿には収まりそうに無く、また別の機会に投稿できればと🙂

ということで本稿では、我々ユーザのスクリーンを占拠するAdネットワーク広告を表示領域ごと非表示にしたいと考えていること、その背景、また実際に実装して動作させている様子もご紹介しました。次回は、スクリーン全体でのWebコンテンツ表示に執着する理由について、別の切り口から書いてみようと思います。