小規模変更するなら『ブロック単位』に徹する事

前回の記事では、AIによるコードレビューについて考えました。

そこで見えてきたのは、AIの性能だけではなく、どの規約を適用し、どのような手順でレビューするのかという「運用プロセス」も重要だということでた。

では、レビューの結果、修正することになったらどうするのか。

今回は、その「変更」の話です。

AIを使って文章やコードを作っていると、「ここの表現だけ変えて」「この処理だけ修正して」と頼むことがあります。

ところが返ってきたものを見ると、

「あれ？　ほかのところまで変わってる……」

変更してほしかったのは一部分だけなのに、前後の文章まで変わったり、別のコードまで書き換わったりする。

もちろん、「この部分以外は変更しない」「既存部分はそのまま維持する」

と毎回細かく指示する方法もあります。

でも、小さな修正のたびに変更範囲を説明するのも面倒です。

だったら、最初から変更する単位を決めて作ればいい。

そこで出てきたのが、「小規模変更するなら、ブロック単位に徹する」

という考え方です。

文書なら「章立て」する、特別な仕組みは必要ありません。

最初から章や節を明確にしておきます。

第1章　目的

第2章　現状

第3章　課題

第4章　改善案

第3章だけ変更したいのであれば、「第3章だけを修正。他の章は変更しない」と指定できます。

さらに細かな変更が多い文書なら、章の中を節に分けておけばいい。

つまり文書では、章や節を変更のブロックとして扱うわけです。

コードなら、生成するときからブロック化前提で、生成する

[環境]

[前処理]

[メイン]

[後処理]

といった形で、AIにコードを生成させる段階から処理を分け、タグ付けし

そして、「以後の変更でも、このブロック構成を維持すること」

をAI側の生成ルールにしておきます。

メイン処理だけを変更するときは、

「［メイン］だけ変更。［環境］［前処理］［後処理］は変更しない」

と指定できます。

重要なのは、変更するときになって初めて分けるのではないということです。

🌸 「最初からブロック分けしないと！」

🐻 「そっかー！」

AIに最初のコードを作らせる段階から、後で変更することを考えて構造化しておく。これが今回のポイントです。

長時間音声をAIで文字起起こしした時と同じ

以前、長時間音声をAIで文字起こししたときにも、似た考え方を使いました。

長い音声を丸ごと処理させるのではなく、音声①｜音声②｜音声③

と分割して扱う。

今回も対象が違うだけです。

音声なら、処理できる単位に分ける。

文書なら、章や節に分ける。

コードなら、処理単位でブロック化する。共通しているのは、

「AIに扱わせる範囲を、人間側で明確にする」

ということです。

「小規模変更にAIは使えない」とは限らない

ここで一つ注意したいことがあります。

今回の話は、

「小規模変更にはAIを使うべきだ」

という話ではありません。

逆に、

「小規模変更にはAIは使えない」

と決めつける話でもありません。

多少なら自分で直した方が早い、と判断する人もいるでしょう。

小さな変更でも、AIに任せたいと考える人もいるでしょう。

コードなら、単純なパラメーター変更なのか、処理内容そのものに関わる変更なのかでも判断は変わります。

そしてパラメーターについて言えば、そもそもマジックナンバーをコード内に散在させず、定数や設定値として管理するなど、変更しやすい構造で作っておくこと自体が制作・運用プロセスの問題です。

つまり、

AIを使うか、人が直接変更するか。

これは利用者が変更内容を見て判断すればいい。

今回伝えたいのは、その先で、「AIを使って小規模変更をする」と判断したなら、変更対象を明確にする。そのための方法の一つが、ブロック単位での変更と言う事です。

生成時点から「変更すること」を考える、AIで何かを作るとき「完成させること」に目が向きますが、実際の仕事では、一度作って終わりとは限りません。

・レビューする。

・修正する。

・追加する。

・削除する。

・差し替える。

だったら、最初から変更されることを前提に作る。

文書なら、章立てをしっかり取る。

コードなら、処理をブロック化してタグを付け、その構造をAIにも遵守させる。そして変更するときには、対象となるブロックを指定する。

AIを使うかどうかまでAIに決めてもらう必要はありません。

・どこをAIに任せるのか

・どこを人が変更するのか。

そして、出来上がったものを採用するのかを人が判断する。

最後に、

前回のAIコードレビューから今回のブロック変更まで、結局共通しているのは、AIはなんでも、自動やってくれる訳ではありません。

「どのように使い」「何をさせるか」という運用プロセスを明確にし

再構成時に考えるのではなく、生成段階から作っておく。

それを行うのが人なのです。