>>783
1) 盤のデータ構造に一貫性がない
　初期状態と思われる述語 board/2 を見ると、X軸では長さ 7 の固定長配列を表現しているが、
　もう一つの盤 myboard/1 を見ると可変長配列で表現している
　盤はある定数を持つ２次元配列なのだから、X軸とY軸の表現方法は一貫性を持つべき

2) 石の表現が適切ではない
　石にはプレーヤの石とコンピュータの石の２種類があり、おそらくそれらを 1 と 2 という
　整数で表現している
　Prolog であれば文字アトムがあるから、それらは player と computer で表現できる
　タイピングが面倒と感じたなら、p と c でもかまわない
　たとえば Prolog と同じ動的型付け言語の Ruby ならば、
　まよわずシンボル :player と :computer で表現する発想になっていたはずだ
　あるいは静的型付け言語の Standard ML であれば、以下に示す直和型として定義する
　　　datatype stone = Player | Computer
　対象とする概念に応じて適切なデータ表現を選択するのは、
　(Prolog に限らず)あらゆる言語におけるプログラミングの基本だ

3) 値域の検査に一貫性がない
　座標値について、述語 get_at/3 では上限だけ検査して下限を検査していない（もし N が負であれば？）
　同様に述語 get_stone/4 ではY軸の座標値について上限だけが検査されていない
　検査しない方針ならそれどよし、検査するならするで想定できるすべてのケースを検査すべき
　いきあたりばったりのコーディングはコードを品質させ、デバッグを難しくする要因になる

（長いので、次レス以降へ続く）