この記事は、2026年6月時点での自分の考えを整理したものです。
世の中の意見や別の立場を否定したいわけではなく、あくまで今の自分にはこう見えている、という話として書いています。
AIや開発現場を取り巻く状況は変化が速いので、今後の経験や環境によって、自分の考え方も変わっていくと思っています。
はじめに
最近、自分の考え方や文章の書き方をルール化して、AIに読ませることを試しています。
たとえば、こういうものです。
- 自分はAIをどう見ているのか
- どういう言い方は避けたいのか
- 何を断定したくないのか
- どういう観点で開発現場を見ているのか
- 設計やレビューで、どんな前提を大事にしているのか
- 記事を書くときに、どのくらい自分主体で書きたいのか
こういう内容を my-thinking-rules.md や my-writing-rules.md のような形でまとめて、AIに読ませる。
そうすると、AIに毎回ゼロから自分の前提を説明しなくても、ある程度、自分の考え方に近い形で文章を書いたり、判断材料を整理したりできるのではないかと思っていました。
ただ、やってみると、これがなかなか難しいです。
最初は「自分のルールを作れば安定する」と思っていました。
でも最近は、少し違う気がしています。
エンジニアの考え方は、技術の流行、現場の制約、自分の経験、AIツールの進化によって、思った以上に変わります。
そう考えると、AIに読ませる自分ルールは、固定された正解集というより、その時点の自分の考え方を残しておく更新履歴 に近いのかもしれません。
この記事では、自分の考え方をAI用にルール化しようとして感じた難しさと、今のところの落としどころを整理してみます。
ルール化したいというより、分身の土台が欲しかった
そもそものきっかけは、Web上で見かけた話でした。
自分の過去記事や発信内容をコンテキストとしてAIに渡して、Web上に自分の分身のようなものを作る。
その分身に、自分っぽい文章を書かせたり、考え方に近い形で記事を書いてもらったりする。
そんな話を見て、少し気になりました。
ただ、そこで気づいたのは、自分にはAIに渡せる「自分の文脈」がほとんどないということでした。
今まで、SNSに自分の考えを書いたり、記事として残したりすることをあまりしてきませんでした。
なので、自分が何を考えている人なのか、どういう判断をしがちなのかをAIに読ませようとしても、材料がほとんどありませんでした。
最近、SNSに自分の考えを書いたり、記事を増やしたりしているのも、理由の一つはそこにあります。
誰かに見せるためだけではなく、あとからAIに読ませられる自分自身のコンテキストを作っておきたい。
そういう気持ちがあります。
ただ、実際にやってみると、これは単に「AIに自分っぽい文章を書かせたい」という話だけではありませんでした。
記事を書くとき。
開発方針を考えるとき。
誰かの案をレビューするとき。
AIに作業を依頼するとき。
そういう場面で、自分が何を大事にしているのかを言葉にしておきたかったのだと思います。
完全な分身を作りたいというより、自分の考え方が毎回大きくずれないための土台が欲しかった。
今振り返ると、そんな感覚に近いです。
そもそも、なぜルール化したかったのか
自分が考え方をルール化したかった理由は、文章を書きたいからだけではありません。
- 新規システムを構築するとき
- 設計方針を考えるとき
- 実装方針をレビューするとき
- 誰かの案にコメントするとき
- AIに作業を依頼するとき
こういう場面で、自分が毎回言っていることがぶれないようにしたかったんですよね。
少し大げさに言えば、自分の中にある判断基準を、外に出しておきたかった。
たとえば、次のような観点です。
- 仕様の背景を確認する
- 変更してよい範囲を決める
- データの正を意識する
- 責務を曖昧にしない
- テストで確認できる形にする
- AIに任せる前に、人間側の前提を揃える
- どこをAIに任せ、どこを人間が見るのかを分ける
こういう観点は、何度も出てきます。
毎回その場の気分で言うより、あらかじめルールとして持っておいた方が安定する気がしていました。
AIに読ませるためでもありますが、自分自身がぶれないためでもあります。
ただ、ここで大きな問題が出てきます。
そのルールを固定できるほど、自分の考え方は安定しているのか。
そして、エンジニアリングの前提そのものは、そんなに安定しているのか。
やってみると、ここがかなり難しいと感じました。
エンジニアの「正しさ」は、けっこう変わる
先に言っておくと、「正しさが全部流行で決まる」と言いたいわけではありません。
技術的に積み上がってきた考え方もあります。
長く残る原則もあります。
セキュリティやデータ整合性のように、簡単に軽く扱ってはいけないものもあります。
ただ、それでも現場で見ていると、少し前まで正しそうに言われていたものが、いつの間にか古く見えることがあります。
プログラミングの世界では、正しそうに見えることがすぐ変わります。
- 新しい言語が出る
- 新しいフレームワークが出る
- 新しい設計思想が出る
- 新しいツールが出る
- クラウドの使い方が変わる
- セキュリティの前提が変わる
- AIツールの性能が変わる
そして、少し前まで「これがベストプラクティスです」と言われていたものが、いつの間にか、
今はあまりやらない方がいいです
みたいな扱いになることがあります。
これが本当に厄介です。
当時は正しかった。
その時点の情報では自然だった。
でも、数年後には前提が変わっている。
こういうことが普通に起きます。
だから、自分の考え方をルール化しようとしても、そもそもそのルールの土台が動いてしまうんですよね。
AIに読ませるためのルールを作ろうとしているのに、そのルールが依存している技術や現場の前提が変わっていく。
ここが、思っていた以上に難しいところでした。
レビューで言っていることも変わってしまう
これはレビューでも起きます。
自分では一貫したことを言っているつもりでも、後から見ると、
前と言っていることが少し違うな
と思うことがあります。
もちろん、理由はあります。
- 新しい情報を仕入れた
- 別の現場を見た
- 以前のやり方でうまくいかなかった
- AIを使ってみて、考え方が変わった
- ツールやフレームワークの前提が変わった
だから、意見が変わること自体は悪いことではないと思っています。
むしろ、変わらない方が怖い場面もあります。
昔の前提にしがみついて、今の現場や今の技術に合わない判断をしてしまう方が危ないこともあります。
でも、レビューを受ける側からすると、毎回言っていることが変わる人に見えるかもしれません。
これはけっこう悩ましいです。
自分としては、学習して更新しているつもりです。
でも、相手から見ると、単にぶれているように見える可能性があります。
このズレを少しでも減らしたくて、考え方をルール化したかったのだと思います。
「今の自分はこう考えている」
「なぜそう考えているのか」
「どの前提なら、その判断になるのか」
そういうものを残しておけば、少なくとも自分の判断の背景は見えやすくなります。
AIに読ませるルールも、すぐ古くなる
AIに読ませるルールを作ると、最初はかなり良さそうに見えます。
- 自分はこう考える
- こういう表現は避ける
- こういう観点を大事にする
- こういう前提なら慎重に扱う
- こういう判断は保留する
こういうものを文章にしておくと、AIの出力も少し安定します。
ただ、そのルール自体がすぐ古くなります。
たとえば、ある時点では「この構成が良さそう」と思っていた。
でも、新しいフレームワークやAIエージェントの使い方を知ると、別の構成の方が自然に見えてくる。
ある時点では「ここは人間が必ず見るべき」と思っていた。
でも、ツールが進化して、ある程度は自動で確認できるようになる。
ある時点では「AIには任せにくい」と思っていた領域が、数か月後には普通に任せられるようになる。
こうなると、ルールを書いた瞬間からメンテナンスが始まります。
ルールを作ることで楽になるはずだったのに、ルールを更新する作業が増える。
これは、ちょっと笑ってしまうところです。
AIに安定してもらうためのルールなのに、そのルールを人間が安定して保てない。
自分が一番不安定という話です（笑）
ただ、これは悪いことだけではないのかもしれません。
ルールが変わるということは、自分の考え方が更新されているということでもあります。
問題は、変わること自体ではなく、変わったことが残らないことなのだと思います。
システム開発では、AIで出力を増やすだけでは済まない
AIを使うと、出力はかなり増やせます。
文章も書けます。
コードも書けます。
設計メモも作れます。
レビュー観点も出せます。
テストケースも挙げられます。
ただ、システム開発では、出力が増えればよいわけではありません。
特にコードは、増えた分だけ責任も増えます。
- 仕様
- 運用
- 保守
- セキュリティ
- データ
- 責任範囲
- チームの合意
- 既存システムとの整合性
AIでコードを量産できても、それをシステムとして成立させるための前提が必要になります。
ここが、AIに読ませる自分ルールともつながってきます。
AIにたくさん出力してもらうだけなら、そこまで難しくない場面もあります。
でも、実際の開発では、
- 何を作ってよいのか
- 何を変えてはいけないのか
- どこを人間が見るのか
- どう確認するのか
- 誰が責任を持つのか
- その判断は今の現場に合っているのか
を考える必要があります。
つまり、AIに読ませたいルールは、単なる文章の好みではありません。
出力を増やすためのルールというより、出力されたものを現場やシステムの中で成立させるための判断基準に近いです。
だから、難しいのだと思います。
文章の書き方であれば、「こういう表現は避ける」「こういうトーンにする」といったルールで、ある程度まとまりやすいかもしれません。
でもシステム開発では、技術、現場、責任、運用、保守が絡みます。
そのため、固定されたルールだけでは追いつかないことがあります。
エンジニアのルール化は、正解集ではなく更新履歴かも
最近思うのは、エンジニアの考え方をルール化するなら、正解集ではなく更新履歴に近いのかな、ということです。
「これが正しい」と固定するのではなく、
今の自分はこう考えている
を残しておく。
そして、前提が変わったら更新する。
以前の考えが間違っていたというより、その時点では自然だった。
でも、今は別の見方をしている。
そういう形で残していく方が、自分には合っている気がします。
これは記事を書くときにも近いです。
- 時事的な話を書くなら、いつ時点の考えかを書く
- 今後変わるかもしれないと書く
- 別の立場を否定したいわけではないと書く
- 自分にはこう見えている、と書く
それは、逃げの表現というより、変化する領域ではかなり正直な態度にも見えます。
AIに読ませるルールも同じかもしれません。
これは絶対の正解です、という形ではなく、
2026年6月時点では、自分はこう考えている
として残しておく。
そして、変わったら更新する。
その更新の積み重ねが、AIに読ませる自分のコンテキストになっていく。
固定されたルールファイルというより、自分の考え方のバージョン管理に近いのかもしれません。
ルールではなく、自分の考え方の土台として残す
ここまで考えると、少し見方が変わってきます。
そもそも技術の前提が日々変わるなら、固定されたルールだけで判断しようとする方が難しそうです。
その都度AIに聞いて、今の前提でのベストプラクティスや注意点を出してもらう。
そのうえで、自分の経験や現場の制約と照らし合わせて判断する。
そう考えると、無理に全部を固定ルール化しなくてもよい気がしてきました。
ただ、自分の考え方を何も残さなくてよい、という話でもありません。
AIに毎回ゼロから説明するのは大変です。
自分自身も、過去にどう考えていたのかを忘れてしまいます。
だから、ルールというより、自分の考え方の土台として残しておく。
- AIに読ませるときの前提にする
- 記事を書くときの温度感を揃える
- レビューや判断で、前と言っていることが大きく変わりすぎないようにする
- あとから、自分の考えがどう変わったのかを見返せるようにする
このくらいの使い方が、自分には合っている気がしています。
固定された正解集ではなく、更新され続ける思考ログ。
そう考えると、完璧なルールを作れないことも、そこまで悪いことではないのかもしれません。
おわりに
エンジニアの考え方をAI用にルール化するのは、思っていたより難しいです。
新しい言語やフレームワークが出ます。
AIツールも進化します。
ベストプラクティスも変わります。
レビューで言いたいことも、経験によって変わります。
だから、ルール化してもすぐ古くなります。
最初は、AIに読ませるための安定したルールを作りたいと思っていました。
でも今は、少し考え方が変わってきました。
AIに読ませる自分ルールは、固定された正解集ではなく、更新され続ける自分の判断基準なのかもしれません。
その時点の自分は、何を大事にしていたのか。
どんな前提で判断していたのか。
どこに違和感を持っていたのか。
その後、何が変わったのか。
そういうものを残しておく。
AIに読ませるためだけではなく、自分自身が今どこにいるのかを確認するために。
安定したルールを作りたいと言いながら、結局は「変わり続ける前提で残していく」という結論になっているのが、少し面白いところです。
でも、それはそれで、AI時代のエンジニアらしい気もします。