カムチョ

web製作やってます。

[カムチョ @kalaming3104]

やっぱりcodex pro *5だと全然足りない。。

[PHPカンファレンス関西2026 @phpcon_kansai]

⚡️ PHPカンファレンス関西2026 開催決定！

🗓 2027年01月16日（土）@京都リサーチパーク

詳細は順次公開予定。
リポストして続報をお待ちください！！！
#phpkansai

[カムチョ @kalaming3104]

@mronge Thanks, let me clarify: after disconnecting, the Mac returned to its normal display, but it stayed unlocked with the desktop visible. I reconnected to lock/sleep the Mac, then tried putting it to sleep from the Mac side. After that, it got stuck and I had to restart.

[カムチョ @kalaming3104]

それでも、iPadで開発するためにGitHub codespaces→vps→rdp.vncと流れてきた者にとってはダンチのユーザー体験享受してる。
来月から課金しよ

[カムチョ @kalaming3104]

Astropad Workbench偶然流れてきて知ったけどめっちゃいいな。
日本語の切り替えも変な癖ないし、マルチモニターユーザーにとってunified displayは神。
iPadの解析度に合わせてくれるから見やすい。

[カムチョ @kalaming3104]

ただ気になるポイントもあって、
・たまにブロックノイズみたいになる。
・セキュアとは言ってるけどその証明やアクセス履歴は欲しい。
・支払いでpaypalが使えなかったので別手段を用意するのがめんどかった

くらいか。

[Matt Ronge @mronge]

Workbench 1.2 just shipped - Remote desktop for your headless Mac from iPhone or iPad.

New stuff:
- Full Screen Unified Display on Mac
- Speech-to-text for non-English languages
- App stays connected in the background
- Improved zooming on iPad/iPhone
- Improved Intel Mac support
- Login stability fixes everywhere
- Option to hide the dock icon

Stick around to the end of the video for a little surprise 😗

[岡本純平｜Lexa Inc. @Okamoto_Lexa]

WEB制作会社を7年経営してわかったことは、

「集客をしたいです」

と顧客に言われたときのヒアリング項目は

・ノーコードかWordPressか
・好きなデザインの雰囲気は？
・好きな配色は？
・集客したい媒体は？
・デザインツールの希望はありますか？

ではなかったということです。

上記のような話から始めてしまうと顧客との目線合わせは困難になることがほとんどでした。

なぜか？手段の話しかできないと、なかなか信頼されないからだと思います。顧客は成果を求めてWEBサイトを用意しようとしていることが99%だからです。

では、どんなヒアリングをすればいいのか。

ほとんどの場合、まずは相手のビジネスを知るところから始めるのがオススメです。

・どんなビジネスなのか？
・お金の流れは？
・人の流れは？
・商品の流れは？
・どんな人が購入している？

このあたりをおさえると顧客のビジネスが理解しやすくなります。

手段にこだわるのは目的が決まってから、というのがぼくたちの教訓です。そのためにまずはデザインや仕様の話よりも前に、顧客のビジネスへの興味を持ってヒアリングしてみることが大切なのだと感じています。

[デジタル庁 @digital_jpn]

Techブログ：MCP（Model Context Protocol）を活用したJグランツ補助金検索システムの実装例

Pythonで簡単に実装できるFastMCPフレームワークを利用し、Jグランツの補助金検索や詳細の取得などの実用的な機能を備えたMCPサーバーを例として紹介しています。
https://t.co/YzbmmtmAPV

[shimayuz ⤴️ AI影分身構築 @Shimayus]

これいいわ！！ありがとうデジタル庁 @digital_jpn !
早速noteを参考にMCPをClaudeCodeに設定して、補助金をリサーチした。設定手順も簡単だし、必要な情報にすぐにたどり着けるのは魅力！

[ガッシー｜Repsona @GussieTech]

Push通知完全に理解したのでまとめました。着手前にこういうざっくり全貌を見たかった。誰かのお役に立てれば嬉しいです。

[カムチョ @kalaming3104]

claud sonnet 4.5ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
/usageが標準機能実装されたのは嬉しいね

[Mojofull @furoku]

■カスタムプロンプト（https://t.co/ABSEcGkcvY）
- Codex CLIの場合、~/.codex/prompts/ に入れる
- Chrome DevtoolsのMCP設定はこちら
https://t.co/FTaDqpS6eK

〜ここから〜
# llmo-audit

## 目的
公開WebページをDevTools経由で詳細調査し、SEOおよびLLMO（Large Language Model Optimization）観点の改善点と施策を抽出する。成果物として、高校生でも理解できる要約と、グラフィックレコーディング風インフォグラフィックHTMLを生成する。

## 前提
- 対象URLはWebブラウザ（Chrome DevTools経由）で直接アクセスする。
- 取得した情報は調査日時点のものであるため、レポート内に日付を必ず記載する。
- 生成したHTMLはローカルの `documents/workspace/YYYYMM/DD/` 配下など、指定ディレクトリへ出力する。

## 入力
1. 対象URL
2. レポート保存ディレクトリ（例: `documents/workspace/202501/01/`）

## 出力
- テキストレポート（分析メモ）
- グラフィックレコーディング風インフォグラフィックHTML（例: `*_infographic.html`）

---

## 手順

### 1. 作業準備
1.1 指定ディレクトリの作成（`mkdir -p`）。
1.2 目的・入力・出力を再掲し、分析のゴールを明文化する。

### 2. Chrome DevToolsでの詳細調査
- `chrome-devtools__new_page` で新規ページを開いて対象URLを読み込む。
- 以下の情報を順次取得し、必要に応じて `take_snapshot` / `evaluate_script` / `list_network_requests` 等を活用する。

#### 2.1 DOM・コンテンツ構造
- `take_snapshot` で主要DOMを俯瞰。
- `evaluate_script` で `document.querySelectorAll('h1, h2, ...')` の結果を収集し、見出し階層とチャンク分割状況を確認。
- `document.characterSet` を取得し、UTF-8以外であれば要改善点として記録。
- `document.documentElement.lang` を確認し、言語設定をチェック。

#### 2.2 メタ情報・リンク要素
- すべての `meta` / `link` タグ（`canonical`、OGP、Viewport、format-detection など）を列挙。
- 必要な `rel="canonical"`、`og:type`、`og:title` などが揃っているかを評価。

#### 2.3 構造化データ・スキーマ
- `document.querySelectorAll('script[type="application/ld+json"]')` の中身を取得。
- Microdata (`itemscope` / `itemtype`) の有無を確認。
- Breadcrumb、Organization、WebSite、NewsArticle等の構造化データが不足していないかを評価。

#### 2.4 クローラー制御とAI指示
- `fetch('https://target/robots.txt')` の結果を確認し、存在と中身を要約。
- `llms.txt` や `ai.txt` などAI向けポリシーファイルが存在するかを調査。
- サイトマップ（XML/HTML）の有無を確認。

#### 2.5 パフォーマンス・リソース分析
- `performance.getEntriesByType('navigation')` および `performance.getEntriesByType('resource')` で以下を測定：
- DOMContentLoaded時間 / Loadイベント時間
- 転送サイズ（`transferSize`）とデコードサイズ（`decodedBodySize`）の合計
- リソース件数・種類
- `list_network_requests` を用い、トラッキングスクリプトや外部ドメインの数を把握。
- 過剰なサードパーティタグや重いリソースの特定。

#### 2.6 コンテンツ評価
- トップヒーローのH1/H2テキストの有無と表現（キーワード・ロングテール・CTA有無）。
- 一次情報（統計・体験談・調査結果）の存在。
- FAQ、表、リスト、結論ファーストのセクションが備わっているか。
- E-E-A-T観点（著者情報、根拠リンク、ブランドストーリー）を確認。

### 3. 分析メモ作成
- 以下のカテゴリで現状と課題・改善案を整理。
1. 技術的基盤（クロール・インデックス・速度・構造化・文字コード・クローラー制御）
2. コンテンツと意図（キーワード戦略、インテントカバレッジ、一次情報の有無）
3. 構造とAI親和性（見出し階層、FAQ、リスト・図表、結論ファースト、内部リンク）
4. E-E-A-T / ブランド信頼（著者・組織情報、引用元、ブランド訴求、AIで言及される根拠）
5. 優先度付き改善アクション（P0/P1/P2やステップ順で提示）
6. ChatGPTなどのLLMでブランド言及・引用が想定される質問を3〜5件挙げる

### 4. インフォグラフィックHTML生成
以下のプロンプト仕様に沿ってHTMLを組み立てる。高校生にも理解できる語彙で、要点を視覚化する。

```
# グラフィックレコーディング風インフォグラフィック変換プロンプト
## 目的
以下の内容を、超一流デザイナーが作成したような、日本語で完璧なグラフィックレコーディング風のHTMLインフォグラフィックに変換してください。情報設計とビジュアルデザインの両面で最高水準を目指します
手書き風の図形やアイコンを活用して内容を視覚的に表現します。
## デザイン仕様
### 1. カラースキーム
<palette>
<color name='ファッション-1' rgb='593C47' r='89' g='59' b='70' />
<color name='ファッション-2' rgb='F2E63D' r='242' g='230' b='60' />
<color name='ファッション-3' rgb='F2C53D' r='242' g='196' b='60' />
<color name='ファッション-4' rgb='F25C05' r='242' g='91' b='4' />
<color name='ファッション-5' rgb='F24405' r='242' g='68' b='4' />
</palette>
### 2. グラフィックレコーディング要素
- 左上から右へ、上から下へと情報を順次配置
- 日本語の手書き風フォントの使用（Yomogi, Zen Kurenaido, Kaisei Decol）
- 手描き風の囲み線、矢印、バナー、吹き出し
- テキストと視覚要素（アイコン、シンプルな図形）の組み合わせ
- キーワードの強調（色付き下線、マーカー効果）
- 関連する概念を線や矢印で接続
- 絵文字やアイコンを効果的に配置（✏️📌📝🔍📊など）
### 3. タイポグラフィ
- タイトル：32px、グラデーション効果、太字
- サブタイトル：16px、#475569
- セクション見出し：18px、#1e40af、アイコン付き
- 本文：14px、#334155、行間1.4
- フォント指定：
<style>
@import url('https://t.co/BQNcYDFjZU');
</style>
### 4. レイアウト
- ヘッダー：左揃えタイトル＋右揃え日付/出典
- 3カラム構成：左側33%、中央33%、右側33%
- カード型コンポーネント：白背景、角丸12px、微細シャドウ
- セクション間の適切な余白と階層構造
- 適切にグラスモーフィズムを活用
- 横幅は100%にして
## グラフィックレコーディング表現技法
- テキストと視覚要素のバランスを重視
- キーワードを囲み線や色で強調
- 簡易的なアイコンや図形で概念を視覚化
- 数値データは簡潔なグラフや図表で表現
- 接続線や矢印で情報間の関係性を明示
- 余白を効果的に活用して視認性を確保
## 全体的な指針
- 読み手が自然に視線を移動できる配置
- 情報の階層と関連性を視覚的に明確化
- 手書き風の要素で親しみやすさを演出
- 視覚的な記憶に残るデザイン
- フッターに出典情報を明記
```

- 上記仕様に従い、評価結果を高校生向けに要約する。
- カードや矢印、マーカーなどの視覚要素をCSS内で定義する。
- `cat <<'EOF' > <output_path>` でHTMLファイルを生成。
- ファイル名は `対象名_infographic.html` など、識別しやすいものにする。
- インフォグラフィック終盤に「ChatGPTで想定される質問例」のセクションを設け、手順3で整理した質問候補（3〜5件）を掲載する。必要に応じスタイルも追加。

### 5. 最終報告
- 生成したHTMLのパスを明示し、ブラウザ確認を促す。
- 追加の改善アイデアやフォローアップタスクがあれば列挙。
- 分析メモとHTMLの整合性（日時・出典）を再確認。

---

## 注意事項
- 取得した数値や設定は日時によって変化するため、必ず調査日を成果物に記載。
- 行った操作や検出した問題は原則としてそのまま記録し、簡略化しない。
- HTML出力は単一ファイルで完結させ、外部依存を最小限に抑える（Google Fontsは可）。
- 生成物を保存する際は既存ファイルの上書きに注意し、必要に応じてバックアップを取得する。

---
〜ここまで〜

@hAru_mAki_ch さんのグラレコ出力を引用しています。このプロンプトは不朽の名作。いつもお世話になりっぱなし。

[Haider. @haider1]

GPT-5-high and GPT-5-codex-high are both excellent for coding

the question is when to use each:

> use GPT-5-codex-high for well-specified, implementation-heavy "just code" tasks

> use GPT-5-high when the work mixes code with reasoning, planning, or explanation (design choices, architecture)

[カムチョ @kalaming3104]

なんつーか、遅いんだよなー。1ヶ月放置も謎だし。本当にバグなら、原因と対処がわからんからまた同じこと起きそうだし。

[Claude @claudeai]

We’ve found and resolved two issues that were affecting quality in some Claude responses. We are continuing to monitor for any ongoing quality issues.

We're grateful to the detailed community reports that helped us identify and isolate these bugs.

[カムチョ @kalaming3104]

わかりやすい。メモ

[カムチョ @kalaming3104]

100ドルプラン出てくれないかな。200ドルはキツイ…

[Alexander Embiricos @embirico]

A bunch of you have been asking for transparency around Codex CLI (and now VS Code extension) rate limits.

We just published our first ranges:
- Average Plus/Team users can send 30-150 messages every 5 hours
- Average Pro users can send 300-1,500 messages every 5 hours

Those ranges might look super wide... because they are given real prod usage! Those are the p25 and p75 that we see in data.

There are also weekly limits. Plus/Team users should be able to get a handful of those sessions in. Pro users should basically _not_ hit limits unless they're scripting.

This is still a work in progress, with tough tradeoffs. For example, the higher we make the 5h limit for Plus, the more likely it is that Plus users will hit their weekly limit. Our approach here leans towards enable fewer, more-productive sessions for Plus, vs more less-productive sessions for Plus.

Thanks for the feedback as we evolve!

[カムチョ @kalaming3104]

メモ

[Alexander Embiricos @embirico]

A bunch of you have been asking for transparency around Codex CLI (and now VS Code extension) rate limits.

We just published our first ranges:
- Average Plus/Team users can send 30-150 messages every 5 hours
- Average Pro users can send 300-1,500 messages every 5 hours

Those ranges might look super wide... because they are given real prod usage! Those are the p25 and p75 that we see in data.

There are also weekly limits. Plus/Team users should be able to get a handful of those sessions in. Pro users should basically _not_ hit limits unless they're scripting.

This is still a work in progress, with tough tradeoffs. For example, the higher we make the 5h limit for Plus, the more likely it is that Plus users will hit their weekly limit. Our approach here leans towards enable fewer, more-productive sessions for Plus, vs more less-productive sessions for Plus.

Thanks for the feedback as we evolve!

[カムチョ @kalaming3104]

メモ

[炎鎮🔥 - ₿onochin - @super_bonochin]

Codex CLI のレート制限はざっくりこんな感じらしい。

・Pro は実質的に無制限（スクリプトからの大量実行とかでなければ）
・Plus / Team には、週ごとの制限と5時間ごとの制限がある
- Plus/Team ユーザーは平均すると5時間ごとに 30-150 メッセージ
- Pro ユーザーは平均すると5時間ごとに 300-1,500 メッセージ
・Plus / Team では『週に数回、集中的に（5時間あたりのレート制限に触れるような使い方で）使う』感じを想定しているので、頻繁に使い続けるなら Pro 推奨