kolmas.tech note

雑記と思索、偏った技術の覚え書き

車を走らせていたら

先行車にこんなものを貼り付けているのがいた。

「突然のエンスト、坂道後退に注意」等という事を声高に主張するような輩はマニュアル車を運転してはならないのではなかろうか。

私はオートマチック限定免許なので、マニュアル車の事は分からないけれども、エンストや坂道後退は運転操作のミスによるものであろう。その自身のミスに起因する問題・迷惑への配慮を、初心者でもないのに1周囲に要求するという感性がどうにも受け入れ難い。そこに不安があるなら、素直にオートマチック車を運転しておいた方が良かろうに。自分の好みでマニュアル車を選んでいる2からには、それを理由に周囲に配慮を求めるのは筋違いではないか。


  1. 初心運転者標識=若葉マークは貼られていなかった。そして初心者への配慮を求めるのなら、若葉マークで十分なのであって。
  2. 類似するオートマチック車が無いような特殊車両、という風貌ではなかった。

生成できても手ずから初心者コーディング

以下のエントリ、の続きのようなもの。 blog.kolmas.tech このエントリで書いた通り、生成AI勃興の今におけるプログラマの役割は、変化する事はあり得ども無くなることはないと考えている。一方で、これからプログラミングを修めようとする人に対して、どのようなアプローチが望ましいのかについては、少し考える所もある。

元・非常勤講師

プログラミング遍歴後半学習と感動に関するエントリでも述べたが、大学院生をしていた傍らで、学部新入生向けの情報技術・プログラミング入門的な科目の講師をしていた。全新入生をカバーするために一学期間に複数のクラスを開講する半必修の科目で、私のような情報技術分野の後期博士課程在学者がよく講師をしていた。教材は全クラス共通のものが元から用意されていて、それに基づいて授業をするのが仕事であった。ほとんどの受講者は、プログラミングの「プ」の字に触れたことすらないレベルの完全な初学者である。

当時のこの科目では、コンピュータやネットワークに関する極々基礎的な内容の座学に加えて、クライアントサイドJavaScript1を使ったプログラミング実習2があった。教材には練習問題も色々と用意されていて、授業時間中に練習問題で手を動かす時間を作ったり、一部は宿題にしたりした。授業時間中の実習は、机間巡視していると教室の全体的な理解具合が大雑把に分かるし、遅れ気味の人にはサポートも出来る。一方で、授業時間内で全てこなしきれないほどには練習問題の量があったし、またそもそも受講学生による授業内容の復習のため、また講師としては各学生の理解度合の詳細な把握もかねて、一部の練習問題を使ってほとんど毎週宿題を出した。

講師の謎眼力

さて、宿題を出したからには提出物の採点をする。提出されたプログラムが練習問題に指定された要件通りに動作する事を確認するのは勿論だが、それが正しく動作する場合もそうでない場合も、そのソースコードの内容まで確認する。私が受け持っていたのは一学期につき学生30人程度のクラス一つだけであるが、それでも地味に大変な作業ではある。それをしばらくやっていると、変な眼力が身につく。学生が自分でプログラミングしたのではなく質問サイト等の回答をそのままコピペして提出してきた時に、分かるようになるのである。明確な基準がある訳ではないのだが例えば以下のような事項について、これまでのその学生のプログラムの癖から逸脱した「良く出来ている」ものが突然提出されてくると、このセンサに引っかかる。

  • 機能要件に関わらない部分の書き方が突然に洗練される。変数・関数の命名とかインデント・空白の入れ方とか、授業でも説明するのだが、初学者がそれらをいきなり綺麗にこなすことは、私の経験上、難しいように見える。
  • 機能要件に対して、無駄に回りくどい解法でプログラムが作られている。例えば、条件分岐と繰り返しの説明が終わったタイミングで出題されたシンプルなFizzBuzz問題に対して、まだ講義で扱っていない配列を使ったプログラムを出してくるとか。
  • 他にも、上手く明文化出来ないのだが、学生自身が新たに体得できたものではない何かが、何故だか見える。

もしこのエントリを学生が読んでいるとしたら、講義課題におけるソースコードのコピペはこのような理由で普通にバレるという事を警告しておく。そのようなバレそうな点を回避する努力をするくらいなら、最初から自分でプログラミングした方が早いし為になる。というか、そもそもその回避努力ができるくらいなら恐らく自分でプログラミングできる3だろう。

謎眼力vs生成AI

勿論、仮に上記のような点が引っかかっても、疑わしきは何とやら、コピペ元の存在確認が出来ない場合に不正として対応することはしない。とはいえ、そのセンサに引っかかったプログラムの特徴的な部分を抜き出してググったりすると、大抵はコピペ元4が見つかったものだ。他には、一学期の中で形成されていった仲良しグループ数人の中に良く出来る学生が一人いて、グループの残り全員がその一人の提出物をコピペしてくる、というパターンもあった。ただ、後者のパターンはともかく、前者のウェブ上に掲載されたプログラムのコピペの発見に関しては、私が非常勤講師をしていた時期5と今には大きな違いがある。即ち上掲のエントリでも触れた生成AIの勃興である。

いつも学期の初めには、コピペについて、引用元を明示しない複製として著作権法上の問題があるし、また上掲のようにバレるので、やるなという説明をしていた。無論、コピペしているばかりでは自分の身に付かないので、科目の履修の意味も無いという事も説明した。しかし、このうち前者の説明については、生成AIが普遍的に利用できるツールとなった今は、少し説明を変えないといけないのだろう。生成AIと著作権の話題は、社会全体としてまだ答えが無い複雑な問題である。バレる件については、上掲の理由は生成AIによるソースコードにも含まれうると思われ、その点で件の眼力により引っ掛ける事は出来るだろう。ただ、明確なコピペ元を特定するのは不可能になる。

当時受け持っていた科目においては、毎週の宿題だけではなく、学期末の試験や最終制作との組み合わせで成績評定していた。そのような複合的な評定基準を取る、即ち授業内容を学生が自分のものにできているかの評価を宿題だけに依存する必要がないと思えば、コピペを特定出来なくても評定はできる。また、少しやさぐれた視点では、コピペばかりで授業内容が身に付かなかった所で困るのはその学生本人でしかないのだから、勝手にすればという気持ちにもなる。大学ともなれば義務教育でもあるまいし、それで追々困った所で自己責任であろうと。

そもそもコピペ是非

とはいえ、やはり授業をやる側としては学生にはちゃんと身に付けてほしいと思う。上述のようにやさぐれてみつつも、身に付いていない学生ばかり本当に送り出してはカリキュラムの意義も無い。ただ、こう思った時に、今日プログラミングを学ぶ学生が身に付けるべきものは何で、それを身に付けるためには自分で手を動かさなければ駄目であるという事は、改めてきちんと理論武装していないといけないだろう。何せ入門レベルのプログラミング課題など生成AIが苦もなく片付けてしまえるのである。自分の手でプログラミングする事の意義が学生にとって分かりづらくなっているだろうと思う。

とはいえ、一概にコピペが駄目かというのは、入門を脱したプログラマの視点からは疑問符が付くかもしれない。何故なら我々、サンプルコードがあったらとりあえずコピペして動かすくらいの事は普通にしているだろう。もしくは、何かエラーが出た時にとりあえずエラーメッセージでググって、Stack Overflow6に投稿された解決策を試してみる、などした事が全くない人が居ようか。少なくとも私はどちらもした事がある。それこそ上掲の生成AIによるソースコード生成も、以前のエントリでも書いた通り、既にプログラマを助ける便利なツールとしての立ち位置は確立している訳であって。

その点では、上掲の著作権等の問題は別に考慮する必要はあるが、実践的プログラミングにおいてはコピペそのものが必ずしも悪であるとは言えない。ただ、それは勿論、自分のプログラムに必要なものが何か分かっていて、その必要なものをコピペしてきているという事も分かってやっているからである。逆に言えば、それを分からないで丸写し的に既存プログラムを持ってくるのは悪である。それは初学者にとっては何の身にもならないし、実践的プログラミングにおいても、その辺に転がっているコードを中身も分からず思考停止的に写してくるなど問題外である。

要件を噛み砕く能力

この「必要なものが何か分かっていて、その必要なものをコピペしてきているという事も分かってやっている」ようになるために必要なのは、言い換えればそのプログラムに対する要件を把握し、かつそれを細分化出来る事であろうと思う。

ここでいう細分化には例えば、このようなライブラリを使うとか、ここでこのようなアルゴリズムを使うとか、そういった大まかな切り分けが考えられる。もしくは、アルゴリズム実装のためにこのような条件でこの類の制御構文をここで使うとか、必要な変数はこれとこれであるとか、そういった細粒度の分解もある。フローチャートを書く、と言っても良いかもしれない。これはある意味、それが出来れば後はそこに利用するプログラミング言語の文法を当てはめれば良い、という段階である。私が、手続き型の考え方を持つプログラミング言語であれば知らないものでも少し勉強すれば書けると思っているのも、思えばこの点を押さえているからである。

もう少し深い所まで言及するなら、先に制御構文という語を示したのと重複する部分でもあるが、この細分化の過程において構造化プログラミングの考え方を理解している事は必要である。全くの初心者にフローチャートを書かせると、制御構造など存在しない、実際にコーディングするとしたらgoto文だらけになるであろう7フローチャートが出てきたりする。また、細分化の過程の中で、関数ないし類似する機能も押さえておく必要があろう。欲を言えば押さえたいポイントは他にも多いが、初心者という観点からは、まずはこの辺りだろうと思う。これくらい押さえておけば、既にあるプログラムを理解する事、また、そこから自分のプログラムに必要な所を組み込む事の下地としての最低限にはなると考える。

それは、上記の通り、また以前のエントリに書いた事にも通じる所として、生成AI勃興の今においてもプログラマに求められる能力であると考えている。逆に、ただ単に言われた通りのフローをコーディングするだけの仕事は、淘汰される方向にあると思う。

センスは実践で磨かれる

ではその能力をどのように身に付けるのか、といえば、結局は手ずから様々なプログラムを作ってみる経験が必要なのだと思う。今日日、前時代的な方法論ではないかという誹りを受けるのかもしれないが、私にはこれより良いものが思い当たらない。

先の「gotoだらけフローチャート」の事を例に挙げれば、そのようなフローチャートでは実際にコーディングする際に手詰まりになる事、またそこからフィードバックして手続きを構造化する事、の実体験が必要だろう。私の講師としての感覚において、一般的なプログラミング言語の制御構文で実現できるフローについて事前に説明していても、それだけで構造化されたフローチャートを描ける初学者は稀である。しかしそれでも、実際に手を動かしながら出来る出来ないと繰り返し考えていると、次第に構造化プログラミングの考え方が頭に馴染んでくる。

最終的には生成AIに代替されうる事であっても、習熟過程では自分で手を動かすべし、というある種の矛盾を孕む不思議な構図ではある。

余談① ー 構造化も生成AIでやってくれるが

構造化プログラミングについて述べたが、生成AIが出力するソースコードも、今時の高級言語を使う以上はその時点でそれなりに構造化されている。要件の処理フローへの落とし込み・構造化も実務的には生成AIに一定程度任せてしまえる。それでも尚、人としてのプログラマが構造化プログラミングを理解している事は必要である。さもなくば、生成AI出力のプログラムの構造を理解・把握する事は出来ないだろう。この分野における生成AIの利用において、それは必要な事である。

余談② ー そもそも要件定義の能力

プログラミングというよりもその上位工程にあたる事だが、要件の細分化以前に、大元の要件を明確化する事が当然必要である。これも、生成AIの存在の傍ら、人の役割であり続けるものだと考える。生成AIがコーディング部分の負担を減らしていく事は確かだろうから、これらの役割は一体化していく方向にあるのだと思う。

プログラムを書く事それ自体を仕事にした経験はないが、野良プログラマとして、自分が必要なプログラムの要件を自分で考えて、それを自分でプログラムを書く所までやる、という事をしている。そのため実は、要件定義とコーディングが分業されるという事のイメージが正直付かない。かの有名な「顧客が本当に必要だったもの」の絵は知っているが。


  1. それが実行されるウェブページを作るためのHTMLについても解説・実習があった。
  2. 私が講師をやめた後の科目内容改訂の中で、プログラミング実習のネタはPythonに変わったらしい。
  3. 言い換えれば、自分がプログラミング出来ない内容をコピペした上でその回避努力をすることは出来ない、ということ。対偶である。
  4. 具体的には、某知恵袋等の質問サイトが典型的である。ご丁寧にも練習問題の文面が質問文にコピペされている事すらある。
  5. 2017年まで。
  6. 例えば。
  7. それ故に今時の主流プログラミング言語ではコーディングしにくいような、もしくは、出来ないような。

石炭動力で石油輸送

プラレールで遊ぶ次男が、蒸気機関車に石油タンク車を繋いでいるのを側で見ていて、石炭動力を使って石油を運ぶ1というチグハグ感が面白いなと思った。現行の熱源である石油を、一世代前の熱源である石炭2で運ぶという、何となく感じられる不条理感。

どことなく不条理を感じる編成。全て黒で揃ってはいるが。

と思ったのだが、よくよく考えてみれば一昔前には蒸気機関車による石油輸送もあり得たのではないかと調べてみる。以下によると明治26年にはタンク車が存在しているらしく、その時代であれば動力は当然蒸気機関車だろう。 ja.wikipedia.org

また、石油を熱源とする蒸気機関車もある・あったらしい。石油を使う機関といえば内燃機関が真っ先に浮かぶが、そりゃあ外燃機関だって熱源さえあればその種類は問うまい。 www.tetsudo.com

何事も調べてみると自分の知らなかった事がボロボロと出てくるものである。


  1. 無論、次男がそんな事を考えているわけは無いが。蒸気機関車も好きだし、貨物列車、特にタンク車も好きなのである。
  2. とはいえ、蒸気機関車はともかくとしても、石炭自体はまだまだ現役で使われている熱源ではある。

受け手次第のランダム性

先のエントリにて応用行動分析の考え方における変動強化について書いた時にふと至った、ランダム性についての思索。

そもそも「ランダム」とは何か

ランダムとは、事象に法則性がなく予測できない事を意味する。例えば、コイントスの結果は一般にランダムであると見做される。コインの表と裏のどちらが出るかは、普通は予測できないからである。では、10回のコイントスでそれぞれ以下のような結果が出る三種類のコインについて、それらによるコイントス結果はランダムと言えるか。

  • 表表表表表表表表表表:「表」しか出ないイカサマコインである。このコインを使った11回目のコイントスの結果は明らかに「表」と予測可能である。その点で、このコインを使ったコイントスの結果にランダム性があるとは言えない。
  • 表表裏表表表表表裏表:「裏」も出るが、「表」が出る可能性の方が高いコインである。次に何が出るか完全に予測する事ができないのである程度のランダム性はあると言えそうだが、大方「表」の方が出そうだとある程度の予測はできる。その点で、表裏等確率のコインによるコイントスと比べたらランダム性は低い。
  • 表裏表裏表裏表裏表裏:ではただ単に「表」と「裏」が等確率であればランダムなのかというとそうも言えない。この「表」「裏」が交互に出るコインを使った11回目のコイントスの結果は明らかに「表」であろう。予測可能であり、ランダム性があるとは言えない。

これは情報理論の極めて基礎的な部分の話題である。ここで言う「ランダム性」というものは、情報理論の文脈で言うところの情報量・エントロピーの概念に通じている。完全に予測できる事象には情報量がない、言い換えれば、情報として保存したり伝達したりする必要性がない。 ja.wikipedia.org 上記の三枚のコインのうち、一枚目によるコイントスの結果は明らかに「表」でしかないのだから、コイントスの結果を保存しておく必要は全くない、つまり情報量がない。三枚目については、最初の出目が「表」か「裏」かだけ保存しておけば、n回目のコイントス結果は保存しておかなくても再現可能である。一方で二枚目については、可能性は低いものの「裏」がいつ出るかは分からないので、それは保存しておかないと再現できない。ただし、「裏」の発生確率が低い事を利用して、コイントス結果を効率的に保存することはできそうである。これは情報圧縮の考え方である。

人力乱数生成、ただし道具の使用不可

上記は、繰り返しであるが情報理論の基本であり、私にとっては大学生の頃に修めた内容である。何の新規性もない。では何故それを突然思い起こしているのかというと、冒頭で述べた通り応用行動分析における変動強化について考えた事である。行動に対して好子を与える事でその行動の定着・強化を図る応用行動分析的手法において、その行動に対してランダムに好子を与えたり与えなかったりする事でより強固にその行動を強化する事が変動強化である。

さてここで、この「ランダムに好子を与えたり与えなかったりする」ためのランダム性をどのように作り出すか。好子の提示にデジタルツールを利用する場面ならともかく、好子を提示するのが人=指導者である場面1では、その「与えたり与えなかったりする」判断を指導者がしないといけない。いわば人力乱数2生成である。ただし、人力乱数の定番手法と言えよう、コインやサイコロ等の道具を使う手法は不可とする。何故なら、好子の提示が直前の行動を強化する応用行動分析的手法において、好子を提示するか否かの判断にそれら道具を使うと、その道具を使う事、即ちコインやサイコロを投げるという行動を強化する事になりかねない。そのため、指導者側である人が、自分の頭の中で好子の提示有無を決めなければならない。

その前提に立つと、ランダムに決めるという事は簡単そうに見えて難しいように思えた。何回かに一回は好子を与える、という考え方は分かりやすく適用もしやすいが、上記例の三枚目のコインと同様でありランダム性があるとは言えない。このようなパターンがある間欠的な強化は固定強化と呼ばれ3、変動強化とは区別される。この内、行動の強固な定着に結び付くのは変動強化4である。しかし、ランダムの考え方を適当にしていると、変動強化をしようとして固定強化になってしまう事がありそうである。

強化したい行動を複数の指導者の内の誰かがランダムに見る、例えば我等が長男の場合には私と妻のどちらが見るかが毎回ランダムである、という事は普通にありそうである。例えば長男に手を洗わせるという事について、それを見るのは概ね私が妻か、もしくは同居の私の両親か、のいずれかで、誰がその場に居合わせたかで変わる。先日生まれた三男の世話もあって、これは全く予想ができない。しかし指導者の人選がランダムであっても、この内誰かが好子を与え、他が与えないという形では、好子の提示という観点ではランダムにならない。人が決まったタイミングで好子の有無が予測できるからである。例えば妻の付き添いで手を洗った時には好子により強化、その他の場合は好子なし、という考え方では、「手を洗うこと」に対する変動強化には全くならない。それは「妻の付き添いで手を洗うこと」に対する連続強化であって、そうしたら長男は手を洗う際の付き添いを必ず妻にせがむようになるに違いない。5

となれば、指導者個々人の頭の中でそれぞれに乱数生成するしかないが、それは人には難しかろうと思う。どうしても、「前は好子を出したから今回は出さない」とか、「しばらく好子を出してないから今回は出す」など、以前の行動に引きずられがちである。これは即ち以前の行動からある程度予測し得るという事だから、完全にランダムとは言えない。以前の事象とは独立にその場限りでランダムに何かを決める、しかもそれを頭の中だけで毎回、というのは案外と難しい。

非ランダム性を認知できなければ実質ランダム

とはいえ、多少ランダム性が損なわれていたとしても、それを悟られなければ十分であるという考え方も出来る。例えば上述の脳内乱数生成、完全なランダム性を求めるのは厳しかろうが、そうである事を相手、例えば我等が長男、に悟られなければ良い。コインやサイコロといった道具や、人によって変わるといった条件は悟られやすいので不可である。その点では、道具を使った乱数生成も、その道具の存在を悟られなければ良く、例えば時計の秒針などは使えそうに思う。好子を与えるか否か決める時、さっと振り向いて時計の秒針を見て、その位置、例えば30秒を過ぎているか否か、で決めるのである。一定程度のランダム性があるだろうし、素早く確認できるので気付かれにくいだろう。

そんな事を考えていると、この、ランダム性があるものとして扱われるか否かが受け手次第であるということが、一般的な乱数生成にも当てはまると思い至る。例えば、ソフトウェア単体で外部入力なく生成できる乱数は、計算で求めている以上、計算方法と初期入力=シードが分かっていれば再現可能である。故にこれは疑似乱数と呼ばれる。擬似とはいえ、人を相手に乱数を使うソフトウェア、典型的にはゲームにおけるランダム挙動の実現等、においては、普通はそれで十分6である。何も知らない人から見たら、疑似乱数は十分にランダムであるように見える。一方で、擬似乱数の仕組みを知っている人は、その仕組みを使ってゲーム内で望む挙動を実現したりする。ポケモン界隈で「乱数調整」と呼ばれる手法7が有名。そのような人にとっては、当該擬似乱数は最早ランダム性を持たない。 www.mizdra.net

また、典型的には暗号学的用途など、乱数の受け手がコンピュータ8である場合には、擬似乱数では不足する場合があり、そのような場合はハードウェアとしての乱数発生器を利用する事もある。これらはハードウェアの不確定性に基づいて真の意味で予測できない乱数列を発生させる。 ja.wikipedia.org

これらは、それぞれにランダム性の度合いが全く異なる。ただランダム性が高ければとにかく良いという訳ではなく、実際に運用する場面に適応出来なければ何の意味も無い。その点で、受け手に非ランダム性を見抜かれない程度のランダム性を持たせておく、という事が重要である。

用途に合った乱数を

という訳で、ここまで散々書いてきた割に、乱数の受け手、ひいてはその用途に合った適切な乱数生成法を使いましょうという、何の変哲もない極めて当たり前の結論に落ち着く。


  1. その場面を生じる分かりやすい好子としては、例えばおやつをあげるとか。
  2. 乱数=random number。
  3. 字面的に紛らわしくて混同しそうだが、強化したい行動の度に毎回好子を提示して強化するのは連続強化。強化を間欠にするのが部分強化であり、その間欠の考え方によって固定強化と変動強化に分かれる。
  4. 固定強化は、好子が与えられるタイミングが決まっているため、その直前以外の行動がおざなりになりやすい、とのこと。
  5. というより、既にその気がある。
  6. さすがにシードは毎回変えてやらないと、専門家でなくても非ランダム性に気付かれるだろうが。
  7. ポケモンのステータスは、そのポケモンの種類と育て方に加えて、個々のポケモンに固有のランダム値で決まる。このランダム値は界隈では個体値と呼ばれ、理想的な個体値を得る等の目的で乱数調整する人がいる。
  8. 暗号に対する攻撃など、悪意ある用途のコンピュータ。

何を強化しているのか

あるいは、何を強化してしまっているのか。

応用行動分析の本を読んだ

副題が素敵1な応用行動分析=ABAの本を読んだ。以前読んだ藤居氏の本の最後で薦められていた本の一冊である。

翻訳本であり、原著2の著者カレン・プライア氏は動物トレーナーの背景を持っている。その背景から明らかな通り、本書は自閉症療育の本ではなく、応用行動分析そのものの本である。ただ、動物だけでなく人間にも適用可能な、根本的な応用行動分析の考え方について説明されており、それは長男の自閉症療育の文脈で聞きかじった応用行動分析の話にもしっかりと通じていた。聞きかじり、の段階から、まとまって整理された本を読んだ事による理解、の段階に進んだのは大変良い事だった。

繰り返しであるが、本書の話題は自閉症療育ではない。自閉症療育において、応用行動分析的手法を活用した療育法は数多あり、それぞれ様々な考え方に依るものであるとの事3だが、それらの解説は含まれない。少し紛らわしいが、件の藤居氏の本においても、応用行動分析そのものと、応用行動分析を活用した自閉症療育法とが混同されがちであるという言及があったように思う。本エントリで紹介する上掲の本は、明確にそれら二つのうち前者を解説するものである。

好子による強化

好子は強化子とも呼ばれる4が、本書では好子と呼ばれているのでそれに従う。好子を提示する事で望ましい行動がより発現するようにする=その行動を強化する事は、応用行動分析的手法の基本である。本書では、この部分について網羅的な解説がなされている。即ち、好子と嫌子、好子による強化、条件性好子、強化スケジュール=連続強化と固定強化・変動強化等の話題が網羅されている。

応用行動分析的手法に対する批判として「餌付け」のようであると言われるのはまさにこの部分であるが、この本にしても長男を見てもらっている療育の先生方にしても、これは否定する所である。まず第一に、ある行動を定着させるために常に好子を与え続けなければならない訳ではない。最初期はそうする=連続強化する必要があれども、一定程度その行動が定着してきたら、好子を与えるか与えないかをランダムにしていく=変動強化にしていく事によって、その行動をより強固に定着できる。その行動自体に内在的な好子が見出されれば、最早それ以外の好子を与えて外部から強化してやる必要もない。

私のような素人にとっては、その連続強化から変動強化へ移行していくタイミング、また変動強化においてもどれくらいの間隔を置くか、という匙加減が難しいところではある。指導者・療育者にとって、ここは勇気が必要な所なのだと思う。今の段階で連続強化をやめてしまったら定着しかけていたその行動が無くなってしまうのではないか、という先が読めない中で、変動強化への移行を踏み切らなければならない。指導者・療育者としての経験が積まれていくと、そのタイミングが見えるようになってくるのだろうか?私は折衷として、好子の量をランダムにするためのタイマーを作ったりした。

条件性好子

「餌付け」論に対する第二の反駁は、条件性好子の獲得である。それこそ食事・おやつといったある意味で生得的な好子を常に使い続ける訳ではなく、他の好子と結びつく事で後天的に好子と認識された何か=条件性好子を用いる。労働に対して与えられる賃金も、他の好子と交換可能である事によって好子となる条件性好子である。賃金を求めて労働する事を「餌付けされている」とは呼ぶまい。条件性好子にも様々な分類があるようで、それは本書では説明されていないが、例えば以下のような解説が見つかる。この解説で挙げられている中で、例えば「行動内在的強化子」はまさに上述の「行動自体に内在的な好子」である。 www.hope.mark-no-juku.com

上掲記事での分類・解説の中では、他に「社会的強化子」が目に止まる。定型発達児と比較したときに、自閉症児は人に対する関心が薄いという。つまり社会的強化子が機能しにくい。その上で何かしらの行動を身につけさせるためのアプローチは「別の類の好子を用いる」か「社会的強化子が条件性好子として機能するようにする」の二択であるように思われる。そう思うと、様々な療育のアプローチを分類できそうである。長男を通わせている療育のうち、ある所で頂くアドバイスには、人との関わり合いが楽しい事である、人と関わると良い事がある、という事を分かってもらうという事に重点がある。これは後者の考え方である。一方、スキル獲得を主軸に置いた考え方の療育も受けていて、そこでのアプローチは前者に近しい。

恐らく、どちらのアプローチも必要なのだろうと思う。様々な物事について、人から教えられたり人を真似したりする事で修得していくと考えれば、その土台として、人とのポジティブな関わり合いから好子が得られるようになっている方が良いだろう。これに必要なのは後者のアプローチである。一方で、それはそれとして早々に身に付けた方が良いスキルもある。例えば生活技能や命名、文字等が考えられ、それらについては前者のアプローチで上記と並行して進めれば良さそうである。

社会性というもの

本書の内容からは外れるが、そのような事を考えると、社会性というものも応用行動分析的な視点で見る事が出来そうに思えてくる。即ち、自分に対する他人の反応には好子たるものと嫌子たるものがあって、その中で嫌子を避け、好子が得られるような行動が強化されていった末に形成されるのが、社会的に適切な振る舞いであるような気がする。手探りで見出す社会性、とでも言えるか。

なればこそ上述の、社会的強化子の条件性好子としての成立は重要である。さらにその時、何が元より好子として与えられたものなのかを理解できる必要もある。例えば他人に怒られるといった、与えている側としては嫌子のつもりの行為が、受けた側には好子として捉えられうる事は、本書でも述べられている。人の反応・社会的関わりという点において、この区別は難しいのかもしれない。人の好意的な反応を条件性好子として成立させる働きは普通になされると思うが、逆の反応を条件性嫌子として成立させる試みは、意図して明示的に5行われまい。子供にしてみれば、どちらも他人の反応が引き出されたという点で好子たるのかもしれない。しかしそれでは、社会的強化子が適切に成立しているとはいえまい。

そう思えば、子供に対して怒るといった、こちらとしては社会的な嫌子を意図している反応を用いる事について、子供にある程度の分別が付かないうちは避けるべき、というのは道理である。そもそも、問題行動をやめさせる方法論として嫌子を用いる事は、本書においてもあまり有効でないとしている。一方で実際の所、これが中々難しくて反省点が多い所である。これもまた本書で指摘されている事だが、我々は問題行動の抑制に嫌子を使う事を強化されてしまっている。これに抗わなくてはならない。更に言えば、アンガーマネジメントも必要である。

何を強化して(しまって)いるのか

応用行動分析の考え方によれば、行動は、その行動の直後に得られる好子により強化される。その点、上述の嫌子の提示による問題行動の抑制は、短期的にはその場の問題行動を収める事が出来る=指導側にとっての好子が直後に与えられるので、強化されやすい。逆に、長期的な取り組みにより効果を期待する類の行動について、その効果そのもののみを好子と捉えて強化する事を狙うのは難しいといえる。応用行動分析的手法を用いてそのような類の行動を強化・定着させる事を狙うならば、長期目標に繋がっていつつ、かつ短期的に個々の行動を強化出来るスキームを組み立てる必要がある。

この、直後の好子が行動を強化するという点、またその点からして考えなければならない論点も本書は指摘している。即ち、その好子が強化している、あるいは、してしまっている行動が何であるのか、分かっていなければならないという事である。典型的な例として、駄々をこねる子供を鎮めるために玩具やおやつ等といった好子を与える行為は、その直前の行動、ここでは即ち駄々をこねる事を強化してしまう。応用行動分析的手法を適用する際には、これを常に意識しなければなるまい。

もう一点、応用行動分析的手法の活用時に留意しなければならない点として本書で触れられている事は、条件性好子を無駄打ちしない事である。強化を意図しない行動の強化に繋がってしまう可能性もある。また、特に強化されるべき事をした訳でもないのに与えられる条件性好子は、その好子としての価値を毀損する可能性がある。極端な例えだが、特に何もしていないのに常に褒められていたら、褒められるという事の特別な価値は無くなってしまう。

好子による強化、という考え方それ自体は極めてシンプルであり分かりやすい。一方で、その実適用については上記のように色々な検討点があり、奥の深さが感じられる。

続き

ここまで、本書の内容から特に好子による強化の部分について諸々の事を書いたが、本書で述べられている事は他にもあり、それについては後続のエントリで触れたい。


  1. 「飼いネコから配偶者まで」である。攻めた副題。この本のことを、妻との間では「飼いネコ本」と呼んでいる。
  2. 原著の題はそんなに攻めたものではない模様。
  3. それら個別のものについては、また別途本を読んでいる所である。欲を言えば、自閉症療育の歴史とともにそれら様々な療育法を俯瞰するような本も欲しくはある。先日読んだ藤居氏の本二冊目は、その目的で読むには少々古い。
  4. 色々な言説をかじってみると、「強化子」という言葉の方が多いように見える。reinforcerという元の言葉の訳(reinforce:強化する・補強する)と考えれば、「強化子」の方が近しかろう。一方、「好子」という言葉にはその反対概念を「嫌子」と表現するときの分かりやすさがある。
  5. 意図せず暗黙のうちに条件性嫌子が成立する事は、ありそうではある。