まずはGemini
①以下で使用する主なブログパーツのサイズをpxで表示してください。
WordPress
Kindle
Note
X
各プラットフォームの主な画像・ブログパーツの推奨サイズ（px）は以下の通りです。
WordPress (SWELL / 一般的なテーマ)
- アイキャッチ画像: 1200 × 630 px (比率 1.91:1) または 1600 × 900 px (比率 16:9)
- 記事内画像: 横幅 800 ～ 1200 px
- サイトアイコン (ファビコン): 512 × 512 px
- ヘッダーロゴ: 横幅 600 px 前後（高さはデザインによる）
Kindle (KDP)
- 表紙画像: 2560 × 1600 px (比率 1.6:1)
- 最小サイズ: 1000 × 625 px
- 著者ページ用写真: 200 × 200 px 以上の正方形
Note
- 見出し画像 (記事トップ): 1280 × 670 px
- クリエイターページ ヘッダー: 1600 × 565 px
- プロフィールアイコン: 500 × 500 px 以上の正方形
X (旧Twitter)
リンクカード (OGP): 1200 × 628 px (比率 1.91:1)
ヘッダー画像: 1500 × 500 px (比率 3:1)
プロフィールアイコン: 400 × 400 px (比率 1:1)
ポスト投稿画像 (1枚): 1200 × 675 px (比率 16:9)
ポスト投稿画像 (2枚): 600 × 600 px (比率 1:1)
完結で非常に宜しいですね。
実は昨日 「パーソナライズ設定」を以下の通り変更しました。
簡潔に、質問の答えのみを出力してください。背景説明、挨拶、補足アドバイスは一切不要です。
②Affinityを使用して、画像のリサイズをしたいのですが、
ベクター、Pixel、レイアウトとありますが、どれから始めるべきですか？
画像のリサイズ目的であれば、**「Pixel（ピクセル）」**から始めるのが適切です。
各モード（ペルソナ）の役割とリサイズ時の判断基準は以下の通りです。
1. Pixel（ピクセル）を選択する理由
写真やブログ用画像、SNS投稿用など、既存の画像ファイルを特定のpxサイズに変更する場合、Affinity Photo（またはDesignerのピクセルペルソナ）でピクセル単位の操作が必要になるためです。
2. 各モードの使い分け
| モード | 特徴・用途 | リサイズにおける役割 |
| Pixel (ピクセル) | 写真やラスタデータ（ドットの集合）を扱う。 | 一般的な画像リサイズに最適。キャンバスサイズやドキュメントサイズの変更を行う。 |
| Vector (ベクター) | 数式で描かれた図形やロゴを扱う。 | 拡大しても画像がボケない。ロゴデザインなどを比率を保ったまま拡大・縮小する場合に使用。 |
| Layout (レイアウト) | 印刷物や複数のページ構成を扱う。 | 誌面などの「枠」に対して画像をどう配置するかを決める際に使用。 |
3. 具体的なリサイズ手順
- Pixelモードになっていることを確認します。
- 上部メニューの [ドキュメント] ＞ [ドキュメントをリサイズ…] を選択します。
- 単位を [ピクセル] に設定し、希望の数値を入力します。
- 比率を維持する場合は、南京錠アイコンがロックされていることを確認してください。
- [リサイズ] を実行します。
チャッピーに聞いてみた
チャッピー劣化したの？
「簡潔に、質問の答えのみを出力してください。背景説明、挨拶、補足アドバイスは一切不要です。」
実は昨日まで設定していた 「カスタム指示」をGenimi同様上記に変更したのだが・・・
それが悪かったの？
お礼のメッセージを考案してください。
ありがとうございます。
スキ、本当に励みになります。
60代からの挑戦をリアルに発信中です。
うまくいったことも失敗も、すべて公開していきます。
少しでも参考になれば嬉しいです。
今後ともよろしくお願いします。
こんな感じだったので、画像だけ投げたところ・・・
スキありがとうございます！励みになります
60代から副業挑戦中です
リアルな過程を発信しています
失敗も含め全て公開しています
35文字以内で入力してください。 という文字が出てますが
スキありがとうございます！励みになります
60代から副業挑戦中です
リアルを発信しています
35文字以内で入力してください。 という文字が出てますが
スキありがとうございます！励みになります
というAIというか、不貞腐れたOLさんに相談したような結果となりましたw
これ、相談したoyajiが悪いの？
4/10
claude code に聞いてみた 100426
これからの時代はAIを使うことは当然ですが、過渡的にプログラミングの最低限の知識としてGithubなどを使いこなすべきだとの意見がありますが、私のようなコンテンツビジネスである程度稼ごうとしている層はどこまでの知識を身につけるべきでしょうか？
⏺ コンテンツビジネスで稼ぐことが目的なら、**技術習得は「手段の最小化」**が正解だ
と思います。
—
結論から言うと
GitHubを使いこなす必要はほぼない。
ただし、以下の3層は押さえておく価値があります。
—
押さえるべき3層
1. 概念レベル（必須）
– バージョン管理とは何か（変更履歴を記録する仕組み）
– APIとは何か（ツール同士をつなぐ窓口）
– ローカル / クラウドの違い
→ AIに正確な指示を出すために必要。知識ゼロだとAIへの質問が曖昧になる。
2. 操作レベル（状況による）
– Claude Code / Cursor などAI駆動ツールの基本操作
– Notionや自動化ツール（Make, Zapier等）の接続設定
→ GitHubそのものより、AIツールを動かすための周辺操作が実用的。
3. コーディングレベル（基本的に不要）
– 自分でコードを書く・読む能力
→ AIが書いてくれるので、コンテンツビジネスの収益には直結しない。
—
「GitHubを学べ」論への私見
この意見は主にエンジニア寄りの文脈から来ています。
コンテンツビジネスにとっては：
┌──────────────────────┬──────────────────────────────────────────────┐
│ 問い │ 答え │
├──────────────────────┼──────────────────────────────────────────────┤
│ GitHubは必要か │ ほぼ不要（AIツールが抽象化してくれる） │
├──────────────────────┼──────────────────────────────────────────────┤
│ 技術知識は必要か │ 概念レベルは必要 │
├──────────────────────┼──────────────────────────────────────────────┤
│ 何に時間を使うべきか │ コンテンツの質・マーケティング・AIへの指示力 │
└──────────────────────┴──────────────────────────────────────────────┘
—
実際に投資すべきスキル
1. AIへの指示力（プロンプト設計） — 最もROIが高い
2. ツールの組み合わせ力 — NoCodeで自動化できる範囲を広げる
3. 何ができて何ができないかの判断力 — 外注・AIへの丸投げの見極め
—
技術を学ぶコストで、コンテンツ制作や集客に集中した方がビジネス的には合理的です
。技術は「使える人を使う or
AIに任せる」前提で、判断できる最低限の理解だけ持つのが現実解だと思います。
────────────────────────────────────────────────────────────────────────────────
ビジネスコストの観点から
オープソース化された 例えば gemma4などの習得によるコスト削減を考慮した場合 本来であればエンジニアが使うべきアプリを使えるメリットがあると思いますが学習コストと必要時間から考慮した場合、やはり手を出さないほうが無難と言えますか
⏺ 結論：今の段階では手を出さない方が無難
ただし理由を整理すると、判断基準が見えてきます。
—
コスト削減の実態
ローカルLLM（Gemma等）で削減できるコスト
┌──────────────┬────────────────────────────────────┐
│ 項目 │ 実態 │
├──────────────┼────────────────────────────────────┤
│ API費用 │ 削減できる │
├──────────────┼────────────────────────────────────┤
│ ハードウェア │ GPU必要（M2/M3 Mac以上推奨） │
├──────────────┼────────────────────────────────────┤
│ 学習時間 │ 最低でも数十〜百時間単位 │
├──────────────┼────────────────────────────────────┤
│ 維持コスト │ モデル更新・環境管理が継続的に発生 │
└──────────────┴────────────────────────────────────┘
現実の落とし穴
–
Gemma4等を実用レベルで動かすにはPython環境構築・量子化・メモリ管理の知識が必要
– 「無料で使える」≠「コストゼロ」。自分の時間が最大のコスト
– Claude /
GPT-4oのAPI費用は、コンテンツビジネス規模なら月数千〜数万円が現実的な上限
—
判断の分岐点
月のAPI費用が3万円を超えているか？
↓
YES → 検討する価値あり（エンジニア採用or外注が先）
NO → 費用対効果が合わない
コンテンツビジネスでAPI費用が月3万円を超えるのは、かなりの規模になってから。
—
本質的な問い
▎ 「Gemmaを習得する100時間」と「その100時間をコンテンツ制作に使う」、どちらがR
▎ OIが高いか？
コンテンツビジネスなら答えはほぼ後者です。
—
現実的な代替案
┌─────────────────────────────────────────┬──────────────────────┐
│ やること │ 効果 │
├─────────────────────────────────────────┼──────────────────────┤
│ Claude/GPTのAPIをNoCodeツール経由で使う │ 学習コスト低・実用的 │
├─────────────────────────────────────────┼──────────────────────┤
│ Perplexity等の定額サービスを活用 │ コスト予測しやすい │
├─────────────────────────────────────────┼──────────────────────┤
│ 特定用途だけ外注エンジニアに依頼 │ スポットコストで解決 │
└─────────────────────────────────────────┴──────────────────────┘
—
ローカルLLMは「技術が好きで時間がある人の趣味」か「大量処理が必要な事業者」向
けです。
コンテンツビジネスで収益を上げることが目標なら、その学習時間は別に使うべきだと
思います。
コメント