画像生成AIで模写 ＜模写はできるが創造できない＞

絵心が無いので絵が描けない。お手本画像があっても見ただけで模写できない。
今時は、画像生成AIを使用すると元画像から簡単に二次創作できるが、法的、倫理的に多くの議論がある。

日本の文化は、模写や二次創作に寛容なようなので、画像生成AIを使用して模写(二次創作)を試してみた。

【模写】
人間がジャケットの写真を見て、イラストを描くように、人間がジャケットの写真を見て言語化し、画像生成AIに入力してイラストを生成した。

人間がジャケットの写真を見て認識するのは同じで、イラストとして出力する作業で使用する道具が、絵筆・描画アプリか画像生成AIかという違いであり、人間の創作的寄与があると認識している。
(二次創作だから、類似性も依拠性もあるのだが．．．)

【素材】
VTuberユニット、みみのん がリリースした、「だいたいハッピー」のジャケット写真を模写してみる。

〈楽曲リリースのお知らせ〉

🌟#みみのん 1st Single『だいたいハッピー』🌟

10/16(金)0時 デジタルリリース
10/16(金)20時 MV公開＠奏みみch.
10/16(金)21時 リスニングパーティー配信＠奏みみch.
10/16(金)21時30分 新告知アリ‼️

▼Pre-add & Pre-saveはこちら▼
https://t.co/8Q7vWArFUQ

リリースからMV公開、配信まで一緒に楽しもう✨

— みみのん / MiMiNoN (@MiMiNoNOfficial) October 10, 2026

【手法】

• 生成AIにジャケット写真を読み込ませない
• 写真を見て、人物の髪形や服装などの特徴を言語化する
• 画面構成を言語化する
• 背景を言語化する
• プロンプトを作成する
• 画像生成AIで生成する

試行錯誤して作ったプロンプト

ここをクリックすると開きます

# だいたいハッピー

## 指示

以下の条件で画像を生成する

## 登場人物

### mimi

- 若い日本人の女性

- 暗い茶髪をお団子にまとめ、前髪があり、顔周りに後れ毛

- 大きめの黒いサングラスを着用

- 人物の右手を鑑賞者・カメラに向かって真っ直ぐ大きく伸ばしているダイナミックな構図

- 首元まである赤いハイネックのトラックジャケット（袖に白い3本線）、黒いショートパンツ

### non

- 若い日本人女性

- 黒髪のロングストレートヘア、前髪あり。

- 大きめの、太い白縁のサングラスを着用

- 人物の左腕を斜下に向かって真っ直ぐ大きく伸ばして、手のひらを上に向けVサインをしている

- 首元まである青いハイネックのトラックジャケット（袖に白い3本線）、黒いスカート

## スタイル

- クリーンなイラストスタイル

- ちびキャラ（デフォルメ強め）

## 配置

- mimiとnonが左右に並んで撮影している

- mimiがカメラをもって自撮りしている

- 2人の視線は同じ方向を向いている

- カメラは画角にの外にある

## 背景

- 余白に「☆だいたいハッピー☆」の文字を入れる

- 人物を囲むように

- 文字の指定：

  - 手書き風

  - 太文字、パステルカラー、黒色の縁取り

  - 文字ごとに色を変える

CopilotのCreatorで生成した画像


気づいたところ。

【プロンプト】
1年くらい前は、ある程度のクオリティの画像を生成しようとすると、「元素法典」などを参照して呪文を書かなければならなかった。
また、キャラクターをデフォルメして「ちびキャラ」を生成しようとすると、
【8つのAI画像生成ツール比較 ちびキャライラスト編】
のような立派なプロンプトを与えなければならなかった。

最近は、呪文を書く必要もないし、「ちびキャラ(chibi)」を指定するだけでデフォルメされるようだ。

【モデルによる差】
同じプロンプトを、CopilotのCreatorの他に、gemini、ChatGPT、Grokに与えて生成してみたが同じような画像が生成された。
モデル固有の指示ではなくても、自然な文章で指示すれば作成者の意図はどのモデルにも伝わるようだ。

【まとめ】
画像生成AIを使用して、ジャケ写を模写してみた。
模写は元の画像があるから言語化できて、プロンプトを作成することができる。
しかし、何もないところから、このプロンプトを作成することは難しい。
頭の中のイメージは写真のように鮮明ではないから、言語化できないのだ。

生成AIを使用することで、画像を生成する作業は簡単になったが、イラストレータの仕事が無くなるわけではないと思う。
出来上がりの絵を鮮明にイメージできるかどうかが、イラストレータと絵心が無い一般人との差だと思う。

---

※プロンプトは生成AIを使用せず人間が書いた。
のんさんのピースポーズが言語化できず、「ギャルピース」ということを教えてもらったが、最後までピースの向きが制御できなかった。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【試してみた】

AIしくじりひとり情シス ＜しくじりポイントは技術だけではない＞

AIしくじりひとり情シス（中堅中小企業生成AI（RAG）プロジェクト中間報告）  清水博  一般社団法人 ひとり情シス協会

失敗事例は、成功事例より学べることが多い。
この本のタイトルは「しくじりひとり情シス」だが、しくじりのポイントは情シスだけでなく、経営的、技術的課題、心理的課題など、多様な観点から解説してある。

【RAGに入力するデータ】
RAGを使用すると、専門的な領域の回答を生成できるが、データを準備する必要がある。
過去のデータや処理の記録があっても、それらを利用して有効な回答を生成できるとは限らない。
例えば、
・基準や規則など、前提が異なる記録
・報告のための記録
を使用した結果、期待する回答が得られなかった事例が紹介されている。

基準や規則が変わる前のデータは、現在の判断に使用できない。
更新前の古い装置を使用していたときのデータや、法改正前の基準を基にしていたデータが、回答に混じり、使用者の判断が誤った事例が紹介されている。

フォーマットが揃っているデータがあると、AIでの利用を期待するが、過去のデータが利用できるかどうかは精査が必要だ。

【答えないことの重要性】
AI特有の網羅的で曖昧な回答が使いものにならなかった事例が紹介されている。
長文、網羅的、両論併記、曖昧な結論は生成AIの回答の特徴だ。
調べ物なら、その回答から自分に都合の良い部分を切り出して使えば良い。

しかし、実際の業務で判断に利用する場合には役に立たないことも多い。
長い回答を読んだ挙句に、判断できる人に聞かなければならないなら、最初からその人に聞いた方が手間が省けて良い。
だから、根拠がある回答以外は曖昧な回答を生成せず、判断できる人にエスカレーションを促すように回答を返す方が良い現場は多いようだ。

【懸念】
この設計は、「人が考えないため」の設計だろう。
入れ替わりが激しい職場では有効だが、ベテランのノウハウは継承できない。

ベテランのノウハウを継承しようとするならば、「人が考えるため」のシステムが必要だと思う。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【雑誌・書籍】

「AIに仕事を奪われた」の今

「AIに仕事を奪われた」のデータは何を語るか――けんすう氏の実証分析が示す「収縮と再構成」の実態 白梟と226人の眷族 note (2026/10/5)
元記事はけんすう氏によるXへのポスト

この記事は、AIによる影響は感覚的な主張になりがちな話題を、実データを用いて考察したものだ。
レスを読んでみると、感覚や身の回りで起こっていることが裏付けられたという人が多い。

【AIによる二極化】
下位層はAIにより代替されるが、新たに上位層の仕事が生まれるという説は従来からあった。
実際に、デザイン業界やSES業界では、この現象が現れているようだ。
ちなみに、翻訳と単純ライティングはAIに代替されている。

【どうやって梯子の上部に飛び付くか】
梯子の下部が無くなったときに、新規参入者はどうやって梯子の上部に達するのか?という問題だ。
この問題は、昔からあって何度か経験した。

1. 通信インフラ保守における障害対応
昔通信インフラ保守業務を担当していたころ、障害修理が、障害探索+部品交換からマニュアル＋ユニット交換・機器交換に変わった。

この変化で失われたものは、障害原因の探索・特定に関する技能や障害の未然防止の意識だった。
マニュアルに書いていない稀に発生する障害対応に時間がかかったり、原因ではない部分を交換したりという弊害が発生した。

当時のベテランたちはその状況を嘆いて、一昔前の修理技術を教えようとするのだが、使わない技術は習得できなかった。

2. デジタル・フォレンジック(DF)における解析作業
黎明期には、解析ツールを自作したり、汎用コマンドを駆使して解析していたが、DFが一般的になってくると、市販の解析ツールが登場した。
市販の解析ツールは操作方法さえ知っていれば、解析結果を出力してくれるようになった。

この変化で失われたものは、
解析対象や解析方法に関する知識や解析結果への責任感だった。
解析ツールを操作するだけの人や解析結果に責任を持てない人が増えると業務に支障が生じる。

当時のベテランたちはその状況を嘆いて、一昔前の解析技術を教えようとするのだが、使わない技術は習得できなかった。

経験則では、現場の努力で「梯子の上部に飛び付く」ようにするのはかなり困難だ。

【研修で対応できるか】
研修を担当しているときもこの問題は大きな課題だった。
研修で教えることは可能だが、実業務で使用しないことは定着しない。
重要なことは、これらは「技能」であることである。
つまり、知識だけではなく身体を使った行動や、現状に合わせて知識をアップデートすることで自分のものになる。

つまり、梯子の下部を経験せずに、いきなり上部に飛び付くのはかなり困難だ。

【どうするか】
AIによる影響は業界により異なるから最適な対策は異なるし、時間的猶予も異なるから、万能薬的な対策は無い。

二極化する業界では、従来のように下部から上部に習得するのではなく、梯子の下部は無いものとして人材育成を設計することが必要だと思う。
ベテランが持つ暗黙知の多くは使えないことを認識すれば、新しい知恵が生まれる可能性は高い。
これができれば、AIの普及により新たに生まれた仕事で雇用が維持できるだろう。

できなければ、ベテランの退職と共に業務が維持できなくなる。
悲観することは無い。新しい仕事を見つければよいのだ。

【結論】
この問題を少し抽象化して、過去を振り返れば、似たような事例はある。
その時にどう行動したか、どうやって生き残ったかを考えると、AI社会に対応することができるのではないだろうか。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

質問をシミュレートするAIエージェント ＜オブジェクト指向が役立つ＞

人格、知識、環境を設定して質問に答えるAIエージェントを作ってみた。
講師をやっている研修で、ロールプレイ用に登場人物をシミュレートする。

まず、簡単な人格から実装。
できることは、権限の付与を許可することだけで、その他の質問は他の人に投げる想定なので、プロンプトは少ない。
プロフィールなどの知識や性格、行動を分けて書いたらそこそこ答えられるようになった。

次に、ちょっと複雑な人格を実装。
プロンプトが多くなってきたので、回答の長さや自然な日本語で回答する、知らないことをAIの知識で補完しない、などの制約は共通のスキルとして実装した。
知識(知っていること)は、ナレッジとして与えるようにしたら、そこそこ答えられるようになった。

次に、主に回答する人格を実装。
この人格は技術者で、技術的なことは答えるが「作業には責任者の許可が必要です」という律儀な性格なので、プロンプトは多めだ。
テスト用の質問を10問用意したら満足に答えられないし、会話を続けるうちに知らないはずの情報を答えてしまう。

「どのナレッジを参照したか」尋ねても答えてくれない。
ナレッジやシナリオの存在は答えない制約が効いているようだ。

AIに分析してもらうと、指示と知識（人格と現状）の記述が完全に分離できておらず、人格の設定に指示が紛れ込んでいることがわかった。
指示と知識を完全に分離して、1つのエージェントで複数の人格を切り替えられるようにリライトしてもらった。
別の人格が必要な場合は、プロフィール、人格固有の行動、知識を記述することで、追加できる。

- 最終的な構成 -
質問対応Agent/
├─ README.md
├─ Knowledge/
│ ├─ 組織・人物・システム情報.md
│ └─ 作業開始前の状況.md
├─ Instructions/
│ ├─ 全人格共通INSTRUCTIONS.md
│ └─ 人格固有INSTRUCTIONS.md
├─ Skills/
│ ├─ common-response/
│ │ └─ SKILL.md
│ └─ unsupported-response/
│ └─ SKILL.md
└─ Tests/
   └─ テストケース.md

後になって考えると、最初からこのような構造を考えて実装すれば良いと思うのだが、つい思いつきで初めてしまう。

プログラムを書くのと同じだ。
思いつきで書き始めて、機能を追加したり、汎用的にするためにコードを追加すると副作用が多くなる。
そして、仕方なく構造を考えてきちんとクラス化する。

わかったこと
生成AIを使用すると、これまでプログラミング言語を使用しなければ作成できなかったシステムを自然言語で実装できるようになる。
プロンプトは自然言語で書ける手軽さの反面、気をつけていないと、構造化が崩れたり、指示が矛盾したり、1つの文に2つの指示を含めたりしがちだ。

また、指示やナレッジの矛盾のチェックや、矛盾があった場合のリライト、テストデータの生成などにも生成AIが使用できるので、作成に要する時間は短縮できた。

オブジェクト指向プログラミングとの共通点が多い。

全人格共通Instructions	基底クラス / 共通インターフェース
人格固有Instructions	派生クラスの実装・オーバーライド
各人格	クラスまたはインスタンス
Knowledge	オブジェクトが参照するデータ
common-response	共通メソッド
unsupported-response	共通の例外処理
人格選択	インスタンス選択 / Strategy切替
知識・権限の境界	アクセス制御・カプセル化

と考えると、プログラミングの基礎(プログラミング言語に非ず)はエージェントの設計に役立つ。

---

職場の人の使用感を反映して実践投入する予定(2026/10/7)

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【試してみた】

特定のAIサービスやモデルこだわる人 ＜AIの使い方を学ぼうよ＞

生成AIが普及してきたのか、AIの使用を勧める会話を聞くようになった。
最近気になったのは、ChatGPTが良いとか、Claudeが良いとか、Geminiが良いとか、特定の生成AIサービスを勧める人が多いことだ。

なぜ、特定の生成AIサービスに拘るのか考えてみた。

【プログラミング言語】
昔々、パソコンが普及してきたときに、簡単にプログラミングできるようになった。
その頃、特定のプログラミング言語を勧めたり、特定の言語でなければプログラミングできないと言う人がいた。
その人たちは、「プログラミング」ではなく「特定のプログラミング言語」を習得したのだろう。

プログラミングでは「何を解決するか」が重要で「どのプログラミング言語を使用するか」は些細なことだ。
プログラミング言語は、開発環境や実行環境の制限を受けることが多いから、制限や処理内容によって選択すれば良いし、目的が達成できるなら、どのプログラミング言語を使用しても良い。
しかし、特定のプログラミング言語を習得した人は、この発想が無いのだ。 

【特定の生成AIサービス・モデル】
同じように、特定のAIのモデルを勧める人は、AIの使い方を学ばず、特定のモデルの使い方を学んでいるのではないだろうか。

特定分野での特殊な使い方や特定の作業では生成AIサービスやモデルの差を比較しやすい。
しかし、複数の作業で構成される業務でAIを使う場合は、AIサービスやモデルはあまり関係はないように感じる。
業務で使う場合は、どの部分に使うか、処理の元になるデータをどうやって用意するかの方が重要で、その労力に比べるとAIサービスやモデルの違いは微々たるものだ。

【AIの使い方を習得する】
特定のAIサービスやモデルを勧める人は、特定の作業に使っているだけで、業務に使っていないのではないかと思う。
言い換えるなら、自分の作業の効率化に使用していて、他人の作業や職場の業務の効率化は考えていないのではないかと思う。

業務に活用するなら、課題を解決することが重要だから、特定のAIのモデルの使い方を習得するのではなく、業務フローのどの部分にAIを使うと効果的かを習得する必要がある。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

AIの生成物のレビュー ＜「スジの悪さ」を言語化する＞

AIで生産性が3倍になった私たちが、チームを置き去りにした話 Zenn (2026/08/19)

AI導入で失敗事例と考察の記事が流れてきた。
投稿者は、製造業でDX推進を担当しているマネージャーらしい。
Zennは脊髄反射のコメントは少なく、コメントに対して投稿者が返信している。

コメントを反映して一部修正した記事が　Noteに投稿されている。

「AIで3倍」の先で、チームが静かに壊れた理由 note (2026/8/23)

構造的な問題は、コメントで指摘されているので、レビューについて考えてみた。

【結論を先に】
レビューする人は暗黙知を形式知化することが重要。
説明する人は、生成とは別のAIにレビューしてもらうことで、レビューする人の負担を軽減できる。

【違和感】
記事によれば、
上司は、「すぐには理解できないが、正しいことを言っているのだと思う」と言い、それ以降レビューしなくなり、
投稿者は若手の報告に違和感を覚えるようになったらしい。

投稿者が若手の説明に違和感を覚えたように、上司は投稿者の説明に違和感を覚えた可能性はないのだろうか？

「違和感を感じる」という指摘は投げやりだから、真っ当な上司ならば、違和感を言語化して説明しようとするだろう。
しかし、「違和感」が全て言語化できるわけではない。
言語化しても、論理的でなかったり、根拠が乏しかったり、主観的であったりする。

【スジが悪い】
昔若かった頃、上司に説明したときに、「スジが悪いなあ～」と言われたことがあった。
二つ三つ質問されて答えに窮すると、「もう少し考えてみて」と言われた。
スジとは何か？どう悪いのか、さっぱりわからなかった。

質問を変えたり、支離滅裂な答えを整理して、悪いスジを言語化してくれる優しい上司は稀にいた。
今考えると、優しい上司は、違和感を言語化しようとしていたのだと思う。

その後、部下から説明を受ける立場になってからわかってきた。
おそらく「スジの悪さ」は失敗から得た経験が暗黙知化したものだろう。

質問と回答の会話の中で暗黙知を形式知化することで、失敗や事故を未然に防いでいたのだろう。

【AIの生成物に対する違和感】
AIを使用した説明資料の出来が良い場合は、「スジの悪さ」や違和感を覚えても、質問を口に出すことを思い止まってしまう。
しかし、上司として、何かコメントしなければならないという責任感から出た言葉が

「すぐには理解できないが、正しいことを言っているのだと思う」

だと思う。

レビューする人にとって、一見出来の良い資料に対する違和感を言語化するための負担は、かなり大きい。
さらに、AIを使用すると大量の資料を作成できるから、それを全て人がレビューすることはできなくなっている。

【レビュー】
この問題の根本的な原因は、AIの出力が「スジの悪さ」を隠蔽することだろう。
だから、上司がAIの使い方を学んだとしても解決できない可能性は高い。
上司がAIを使用してレビューできるなら、企画を考える人がAIを使用してレビューした結果を上司に説明すればレビューすれば良い。

上司が持っている暗黙知を形式知化する作業にAIを使うと効果が高い。
形式知化できれば、それをAIに実装するのはAI推進担当の仕事だ。

【結論】
レビューする人は暗黙知を形式知化することが重要。
説明する人は、生成とは別のAIにレビューしてもらうことで、レビューする人の負担を軽減できる。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

SaaSの終わり ＜当面終わらないと思う＞

年$600,000のSalesforce契約は、2ヶ月で作った自作CRMに置き換えられるのか？ 中島聡 note (2026/8/16)

中島聡氏の有料メルマガの要約。
元記事は

Curative CEO says company ditched a $600k-a-year Salesforce contract after vibe-coding a CRM in 2 months医療保険のスタートアップ Curative社がCRMをvibe-codingで内製し、Saleseforceを解約したという内容だ。

中島聡氏の要約を読むと、「SaaSの終わり」とAI使用拡大によるAIの使用量の増加について、見解を述べておられる。
機械要約の影響なのだろうか、既視感が強い記事のような感じだ。 
メルマガには、これらのテーマを深掘りしたり、別の観点があるのかもしれない。

[B! AI] なぜ日本企業のAI導入はこんなに遅いのか？｜中島聡 はてなブックマーク
はてな民は反応しているけれど、日本の会社ではAIが使えないという、ありふれた内容が多い。
もっと炎上しているのかと思ったのに．．． 

 閑話休題

「SaaSの終わり」について考えてみた。
元記事は年間60万ドルの契約を解除したという、センセーショナルな見出しだが、このケースは一般的ではないと思う。
Curative社はスタートアップだから、Saleseforceを解約して、内製したCRMに置き換えられるのだろう。

【スタートアップの特殊性】
スタートアップの間は、可用性や機密性より事業拡大が重要だから、vibe-codingで内製したシステムでも良いだろう。
保守上の問題が発生したら、改修せず、新たに作り直す方法もある。　なにしろ、2か月で作ることができるのだから。
また、セキュリティ上の問題で炎上したら、会社を閉じて別の会社を立ち上げる選択肢もある。 

【スケールしたら】
 首尾よく、事業がスケールしたときに、問題になるのは、内製したシステムのスループットやレスポンスタイムが確保できることだ。
つまり、ストレスなく使えることが必須だ。

また、保守の負担も増えるし、保守しないことのリスクも大きくなる。
さらに、セキュリティ対策の不備は、一発アウトに繋がる。

 これらの問題は、vibe-codingでは解決できない。
なぜなら、AIが持っていない、経験と知見が必要だからだ。

AIの使用によるコーディングの効率化が一般的になってきて、専門知識を持っている人も、持っていない人もAIでコーディングしている。
ところが、ただ動くだけのシステムと、可用性、保守性、セキュリティの要件を満足するシステムでは、ビジネス用途としてのクオリティが大きく異なる。

少ないトラフィック、少ないデータ、少ない個人情報しか扱わず、攻撃者に見つからない間は、差は見えないだろう。
しかし、トラフィックが増え、データが増え、扱う個人情報が増え、更に攻撃者に発見されたら、大きな差が出てくる。

だから、内製を続けるならば、サービスを継続するために、専門のエンジニアを雇用しなければならなくなる。

【SaaSのメリット】
SaaSの使用料には、可用性の確保、セキュリティ対策の費用が含まれている。
スケールアウトすると、大きなリスクを取ることができなくなるから、リスクは転嫁した方が合理的だ。

つまり、当面「SaaSの終わり」は無いと思う。

【結論】
スタートアップ企業が、SaaSを使わないという選択肢はある。
スケールすると、SaaSを使う方が合理的だ。
SaaS企業は、スタートアップが解約しても困らないだろうが、「SaaSの終わり」というイメージは払拭したいところだ。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

IT・情シス DXPO 東京 '26 ＜ほぼAI展＞

IT・情シス DXPO 東京 '26 に行ってきた。

【感想】
サービスの展示が多く物の展示がないため、どこも同じようなブースに見える。
説明員が多く呼び込みをやっているのだが、会社名を言われてもわからないし、サービスを言われてもありふれている。
足を止めて話を聞いたブースは、呼び込みや看板の「キーワード」で引っかかった。

作業レベルでのAIの使用は一般的なユーザまで広がってきているようだが、AIエージェントの活用についてはまだ広がっていないようだ。
AIの話題を追っているので、世間とのギャップを感じた。

【展示】
・AI電話
音声ボットが何社から出展されていた。
実用になってきた STT、TTSをAI-Chatの入出力インターフェースにするアイディアは以前からあった。
実際の問い合わせ電話に応答して、要件を聞いて担当者に取り次ぐくらいはできるようになったようだ。

・営業のプロセス"見える化"マネジメント
AIで処理する前に、プロセスの見える化が必要って、ごもっとも。
書籍をもらった。ありがとうございます。

・手書き風DMサービス
プロッターで手書き風の手紙を書くサービス。
400字くらいのサンプルがあればすべての文字が書けるらしい。

手作業にこだわる人はどう感じるのだろうか?

・電波遮蔽フィルム
IT関係ではない、遮熱フィルムが展示されていたので、話を聞いた。
IT関係の話題として、電磁波の遮蔽効果もあることを紹介していただいた。
特定の帯域だが、60dB減衰する製品は多くない。
30dBくらいだと、携帯は圏外にならない。 携帯を使えなくする用途での、引き合いが多いらしい。

• 銀行：ATM周りで使用し、振り込め詐欺対策
• コンビニ：トイレでのサボり対策
• 大学：カンニング対策

【セミナー】

・ひとり情シスによる生成AI導入しくじりのリアル
(一社)ひとり情シス協会 事務局　清水博

清水博によると、IT投資は直接的にROIや生産性、収益性に反映されるわけではなく、組織や人材に関する課題解決と組み合わさったときに効果を発揮するらしい。
技術は加速装置であるから、企業に元々あるものを増幅するとおっしゃる。
だから、AIも導入しただけでは効果は期待できない。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】【展示会】

Copilot Coworkの従量課金 ＜RPAを使うとタダだけど．．．＞

Copilot Coworkを従量課金で使っている。
課金は青天井では心配なので、全体と個人で月間使用量の上限を設定している。
先日、短期間で個人使用量の上限に達したユーザがいた。

• 大量のファイルを定型処理
• 大量のファイルの分析
• 分析結果から資料作成

を実行したらしい。

いかにも、Copilotクレジット(課金単位)を消費しそうな重い処理だが、いずれのタスクもM365 Copilotライセンスで実行できるから、課金せずに実行することも可能だ。

定期的に実行したり、データが変化したときに自動的に実行するタスクは、従量課金されることになるから、M365 Copilotライセンスで実行可能でも無駄というわけではない。

ほぼ1人情シス的には、これまで、RPAスクリプトを作成して業務を効率化してきたので、もう少しクレジットが節約できるのではないかと思ってしまう...

つい貧乏根性が出てしまったので、効率化、費用対効果、上限の設定の観点で考えてみた。

【業務の効率化】
業務効率化の観点では効率化の効果は大きい。
今回の処理は、処理対象のファイルが大量にあるからAIを使用することで、作業時間は大幅に短縮される。
また、定型処理→ファイル作成、分析→資料化など、連続して処理できるため、業務を効率化できる。

【費用対効果】
短期間で個人の上限までクレジットを使用しているが、使用者の賃金(年収/稼働日数)と比較すると高額ではない。
一方で、処理時間は短縮されているから、費用対効果は悪くない。

【クレジットの節約】
RPAやスクリプトの作成能力があれば、クレジットを節約することは可能だ。
しかし、これらの作成能力を習得するにはコストが必要である。
つまり、コストをかけてこれらの能力を習得しなくても、AIを使用することで、業務が効率化できる時代になったということだ。

【上限の見直し】
現状で処理できないくらいのデータがあるならば、AIの使用は有効だ。
そうでない場合は、処理時間を短縮すると、余剰時間が生まれる。
問題は、発生した余剰時間を使用して、効果のない作業をやってしまうことだろう。

例えば、必要のないデータを処理したり、処理を複雑にしたり、求められていない出力を生成してしまう。
時間短縮は目に見える効率化だから、処理することが楽しくなり、手法が目的化してしまう。

これを防ぐために、個人の上限は大きく変えず、上限に達したときに、処理を見直すきっかけにしよう。
処理しているタスクにより、

• 個人の上限を引き上げる
• 組織的に処理するタスクとして別管理にする
• 他の作業の効率化を検討する

などだ。

【まとめ】
M365 Copilotライセンスがあっても多くの人は、Coworkを使用して業務の効率化に活用していない。
クレジット使用量が個人の上限に達する人は、業務を効率化しようとしている人だから応援したい。
また、情シスも現場が必要としている処理について情報を得ることができる。

データ量と処理時間と結果(出来ばえ)を、経験値として持っておくことは重要だ。
今後、一般論ではなく説得力がある説明ができたり、効果的な使い方ができるようになることを期待している。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】

AIの出力で満足している人はセンスがない ＜「センス」が説明できない＞

「AIの出力で満足している人はセンスがない」という言葉がバズっているようだ。

元記事は、米村歩氏のXへの投稿で、自分は「センス」が無いと思っているので、引っかかってしまった。

AIの影響でデザイン業の倒産が増えているという話を聞いて、AIのデザインで満足している人はセンスがないとか言っているデザイン関係の人達を見ると、こういう人達の会社から倒産していくのではないかと感じる。「センス」という言葉で片付けて具体的に言語化しないのは致命的にセンスがないと感じる。

— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) August 4, 2026

【結論】
自分は「センス」という言葉を理解していないことが分かった。

---

以下の観点で考えてみた。

• デザイナー業界におけるAIの影響
• AIとセンスの関係
• センスの言語化

【業界の事情】
デザイン業界は、AIの普及で業界が縮小し、会社の廃業、デザイナーの失業が発生しているらしい。
このような環境の変化には抗いようがないので、業界も個人も適応するしかないし、以前から指摘されていたことだ。

翻訳業界での似たような例について、「もうすぐ消滅するという人間の翻訳について(2025/02/18)」に書いた。

【AIとセンスの関係】
AIの出力には「センス」がないことは、多くの人が感じているだろう。
「ありきたり」とか「AI臭さ」と表現されることもある、「アレ」だ。

では、AIの出力で満足する人にはセンスがないのだろうか?

満足するかどうかは場合によると思う。
仕事で使うなら顧客の要望で決まるし、個人で使うなら使用目的で決まる。
「センス」が必要ならば、AIを使う人が付加すればよいし、「センス」が必要ないならそのまま使えば良い。

だから、AIの出力で満足する人が増えたのは、「センス」が必要ない使い方が多いということだろう。
極論すれば、これまで、「センス」が必要ない顧客に対して、高額な「センス」込みの成果物を提供していたのかもしれない。

【センスの言語化】
正直なところ、「センス」の定義がよく分からないので、言語化できない。

グラフィックデザインに関するセンスは、[デザイナー不要論の正体]、
Webデザインに関するセンスは、[【AIは知らない】WEBデザインに必要なのはセンスではなく知識という事実]
に言語化されている。(すばらしい)

では、自分の業務に関するセンスとは何か、と考えてみたのだが、ノウハウとの違いが分からない。
先に挙げた例はいずれも、特定分野のセンスだから、もう少し抽象化しなければ、自分の分野に応用できない。

【分かったこと】
分かったことは、自分が「センス」を理解していないことだ。
学ぶ必要がありそうだ。

【ところで】
冒頭の投稿は結構バズっているのだが、コメントしている皆さんは、同じ「センス」の認識で議論、コメントしているのだろうか?

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】【AI】