これは、私(tshikimi)が日々の開発・分析・音楽制作で使っている「AI と一緒にものづくりをするときの型」をまとめたページです。万能のテンプレートではなく、あくまで今の自分にとって効いている枠組みの記録として読んでもらえると嬉しいです。世の中の流れは速いので、半年後には中身が変わっているかもしれません。それでも、土台にある考え方は長く使えると信じています。

前提: 私にとっての AI

このページ全体を貫く前提を、最初に一言だけ。私にとって AI は「最強の協働者」です。単なる出力機械ではなく、意図を渡すと一緒に考えて、時には自分より鋭い視点を返してくれる存在として扱っています。だから、AI に任せた瞬間に思考を手放すのではなく、逆に「何を手放してはいけないか」を強く意識するようになりました。

AI を相棒にすると、自分の美意識や判断基準こそが希少資源になります。コードを書く速度や楽器を弾く器用さよりも、「何を良しとするか」を明確に言語化できることのほうが、ずっと大事になってきたのです。

共通原則

開発でも分析でも音楽制作でも、AI と協働するときに自分が守っているルールは、結局のところ同じ四つに落ち着きます。

1. 意図を正確に渡す

AI に仕事を任せるときに最も重要なのは、最初の一手で「何を作りたいか」「なぜそうしたいか」を明確に伝えることです。曖昧な指示は、曖昧な成果物にしかなりません。逆に、意図が十分に言語化されていれば、AI は驚くほど正確にそれを実装・再現してくれます。

意図を渡すときに自分が意識しているのは、次の三層です。

  • 目的: 何のためにそれを作るのか(ビジネス上・読者体験上のゴール)
  • 制約: 使っていいもの・使ってはいけないもの(スタック・時間・コスト)
  • 成功条件: 完成したと言える状態の定義(誰が何を感じればよいか)

この三層が揃うと、AI は手戻りの少ない実装や分析を返してくれます。

2. レビューを手放さない

AI の出力はしばしば「それっぽい」けれど、自分の目で確かめないとわからない細部があります。だから、生成された成果物をそのまま採用するのではなく、必ず自分の目で一度は通すようにしています。レビューのコツは「どこを疑うか」を事前に決めておくことです。

  • コードなら: 型と境界、エラー処理、無駄な抽象
  • 分析なら: データ定義、欠損の扱い、可視化の誤読余地
  • 音楽なら: 構成の単調さ、帯域の濁り、感情曲線の不自然さ

何を見るべきかを最初に言語化しておけば、レビューは機械的に回せます。

3. 美意識を介在させる

AI は「正しい」答えを出すのは得意ですが、「美しい」答えを出すのはまだ難しい場面があります。美しさは、多くの場合「引き算」から生まれます。AI は足し算が得意なので、人間の役目は、出力された候補を削って磨くこと。私は、この「削る作業」こそが AI 時代のクリエイティブの核だと思っています。

4. 学習ループを短くする

AI とのやりとりは、ほぼ即時でフィードバックが返ってくるので、小さく試して小さく反省するループが回しやすいです。大きな設計を一発で完成させようとするより、1 日に 20 回の小さな往復で試すほうが、ずっと遠くまで行けます。自分の中では「一手ごとに仮説を更新する」くらいの感覚で付き合っています。

開発ワークフロー(Claude Code + Codex CLI)

AI エージェントと一緒にコードを書くときは、だいたい以下の順で進めます。

  • 要件のスケッチ: まずは日本語で、何を作るのか・どんな画面や API が欲しいのかを箇条書きにする
  • 設計の対話: Claude Code に要件を渡し、ファイル構成や関数の切り分けを一緒に考える。怪しいところは必ず「ほかの選択肢は?」と追い返す
  • 実装: 設計が固まったら、Claude Code に具体的な実装を依頼する。差分を必ずレビューしてから採用
  • セカンドオピニオン: 複雑な判断が要る場所では Codex CLI にも同じコードを見せ、別のモデルの視点でレビューを受ける
  • 動作確認: 小さな手動テストを手元で回し、必要なら最小限の自動テストを追加する
  • 文書化: コミットメッセージと PR 説明は自分の言葉で書く。ここを AI に委ねると、半年後の自分が未来の履歴を読めなくなります

大事なのは、AI にすべての意思決定を委ねないこと。特に「何を作らないか」の判断は人間側で握り続けます。

BI 分析ワークフロー

本業のアナリストとしての文脈では、AI の使い方は少し違います。扱うのはデータとビジネスの現実なので、誤解釈が大きな痛手につながるからです。

  • 問い直し: 依頼を受けた質問を、AI に別の言い方で言い換えてもらう。隠れた前提や定義の揺れを炙り出すため
  • データ確認: スキーマ定義と欠損率の簡単な要約を AI にまとめてもらい、自分の先入観を再点検する
  • クエリ設計: SQL の下書きを AI と一緒に作る。ただし、ロジックの読み替えは必ず人間が行う
  • 可視化: 「読者の視点で誤読される余地はあるか」を AI に意地悪に突いてもらう
  • レポート: 結論の文章は自分で書く。AI は構成の叩き台に留める

分析の世界では、「AI が出した数字」ではなく「AI と一緒に確かめた数字」として世に出すことを意識しています。

AI 音楽制作ワークフロー

詳しくは Music Made With AI にまとめていますが、基本の流れだけをここにも書いておきます。

  • 作りたい空気感と情景を、自分の言葉で 200 字以内にまとめる
  • 参考になる既存曲の要素(テンポ・楽器編成・雰囲気)を言語化する
  • Suno AI にプロンプトとしてまとめて渡し、複数バリエーションを出力
  • 候補の中から、感情曲線が自然なものを選ぶ
  • 必要なら DAW に読み込んで、ミックスの微調整を行う
  • 最後に「これは自分が作ったと胸を張れるか?」を問う

この最後の問いが、自分にとって AI 音楽の品質管理の中心です。「生成した」のではなく「AI と作った」と言えるまで、出力は何度でも磨き直します。

品質チェックリスト

領域を横断して使える、自分用の最終チェックリストです。

  • 誰に何を届けたいかを一言で言えるか
  • 自分の意図から外れた部分はないか
  • 不要な要素を削れる余地は残っていないか
  • 半年後の自分が読んで意味がわかるか
  • 他人に見せて恥ずかしくないか

どれかひとつでも曖昧ならば、もう一周やり直す。これが自分のリズムです。

最後に

AI との協働は、道具の話ではなく姿勢の話だと感じています。速度や効率は副産物であって、本質は「自分の意図を明確にする訓練」にあると思っています。だからこそ、このワークフローは完成品ではなく、今後もアップデートしていくもの。このページも、実践の変化に合わせて書き直していくつもりです。