0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Trueful番外編1 : プロジェクトとAIの付き合い方

0
Posted at

本編ではTruefulの設計思想やアーキテクチャの話を中心に書いていますが、今回は番外編として、開発の裏側で「AIとどう付き合っているか」を整理しておこうと思います。

最近はAI生成コンテンツに透かしを入れる動きなど、AIとの協業を明示する流れが強くなってきています。隠す理由もないので、実態をそのまま書きます。

透かしの話

きっかけの一つが、AnthropicがEUのAI Act対応として、2026年8月2日以降にリリースされたClaudeモデルの生成物に透かしを入れる、というニュースでした。生成されたテキストには不可視の電子透かしが埋め込まれ、対応するファイル形式には来歴を示すメタデータが付与される、という仕組みです。オプトアウトはできず、API・Claude.ai・Claude Codeなど全プロダクトが対象になります。

正直これを知った時、「コードは自分で書くにしても、Claudeとのやり取り自体はどのみち残るし、いずれバレるやつだな」と思いました。ただ考えてみれば、バレて困るとしたら「人間が一人で作った」と偽ってる場合であって、自分はそもそも最初からAIと一緒に作ってると公言するつもりだったので、透かしがあってもなくても書く内容は変わらないな、というのが今回の記事の出発点です。

透かし自体は「AIが手柄を横取りするもの」ではなく「これはAI生成物ですよ」と示すための仕組みなので、正直に付き合い方を書いておけば、後から透かしで発覚しても「最初から言ってたな」で済む話だと思っています。

なぜ書くか

Truefulは設計・仕様書を先に固めてから実装に入る、というスタイルで進めています。この過程で普通にAI(Claude)と壁打ちしていますし、これから始める実装フェーズも、コードは自分の手で書いて、Claudeには問題点を指摘してもらう形で進めるつもりです。

「AIを使っているかどうか」を後から詮索されるくらいなら、最初から書いておいたほうが早いし、変に隠すことでもないと思っています。

3層で考えている

自分の中では、AIとの関わり方を大きく3つに分けています。

1. 設計・判断 — 自分

Truefulの19原則やアーキテクチャの意思決定(Electron over Tauri、better-sqlite3の採用、Inspector Agentの3層モデルなど)は、自分で考えて決めています。ここをAIに委ねることはしていません。方向性を決めるのは人間の役割だと思っているからです。

2. 相談・添削 — 先生役

設計で迷ったときの壁打ち相手として使っています。例えば「この設計で本当に大丈夫か」「この判断の弱点はどこか」といった形で、答えを教えてもらうのではなく、こちらの考えの穴を指摘してもらう使い方です。

コードや文章の添削も同様で、「直して」ではなく「なぜこれが問題か」を聞くようにしています。丸投げにしない、というのが自分の中でのルールです。

例えばコード添削では、書いたコードをそのまま直してもらうのではなく、「ここの設計、何が問題か指摘して」という聞き方をしています。修正版をもらって終わりだと、次に似た問題にぶつかったときにまた同じところで詰まるので、指摘してもらった理由の方を自分の中に残すようにしています。

3. 実務作業 — 助手役

一方で、定型的な作業はAIに任せています。具体的には:

  • 今日やったことの整理
  • Qiita記事(本編)の下書き
  • GitHub用のADR(Architecture Decision Record)
  • 開発日記

これらは形式がある程度決まっている作業なので、AIに一次稿を作ってもらい、自分で内容を確認・修正する形にしています。ここは正直、素直に「助手」と呼んでいい使い方だと思います。

正直どれも効果を感じていて、優劣をつけづらいです。ADRや開発日記は「後で見返せる形に残す」という地味だけど大事な作業を肩代わりしてもらえますし、Qiita下書きは書き始めるハードルを下げてくれます。今日やったことの整理は、それ自体が次の日の作業の見通しにもなるので、一番日常的に助けられている作業かもしれません。

ルールを破りそうになった話

「丸投げしない」と決めてはいるものの、正直何度か崩れかけたことがあります。

一番きつかったのは、システムの処理順序がどうしても頭に入ってこなくて、パンクしかけた時です。設定ファイルの修正が絡んでくると、共通規格からどこまではみ出していいのか、共通規格自体はどこに保存すべきか、命名規則はどう揃えるべきか、といった細かい判断が一気に積み重なって、正直「もう全部答えだけ教えてほしい」という気持ちになりました。

そういう時は「答えだけ」を求めがちになるので、意識的に「なぜそうなるのか」の説明を先にもらってから、自分で手を動かすようにしています。パンクしそうな時ほど丸投げの誘惑が強くなる、というのが正直な感想です。

まとめ

  • 判断は自分相談は先生役雑務は助手役 — この3層で切り分けている
  • どの層でも、最終的な意思決定や公開する内容の責任は自分にある
  • 隠す理由がないので、今後もこういう形で明記していくつもりです

本編の技術的な話は引き続き別記事で書いていきます。番外編は今後も、必要になったタイミングで追加していく予定です。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?