Objective-C 再入門

普通に iPhone アプリを使うなら swift でいいんだろうが、既存の C/C++ ライブラリを組み込んで使うような場合などは、Objective-C も検討せねばならないだろう。

特にレガシーなプロジェクトなぞ、本体が Objective-C で書かれているので、swift に移植するにせよ、ある程度の Objective-C の理解は必須だろう。

なぜ Objective-C はとっつきにくいのか?

ところで、Objective-C のクセの強さは、万人の知るところだが、これは歴史的背景を考えると理解しやすいかもしれない。

C にオブジェクト指向の思想を取り込むために、大雑把に二つのアプローチがあったようだ。

一つは言語自体の設計を変えてしまう方法。これが現在の主流で、 C++ の源流となっている。

もう一つは、C のコンパイラー自体には大きな変更を加えず、文法的な表記に特殊仕様を入れ、パース時にこれを解釈して、オブジェクトを取り扱えるようにする方法。Objective-C は、どちらかといえば、こちらだろう。

だから、C++ 感覚で取り組もうとすると訳のわからないことになってしまう。

また、Objective-C がとっつきにくいのは、ビギナー向けのほとんどのサンプルが Mac や iPhone の GUI アプリだという点。これだと、Objective-C の勉強というよりも cocoa などの勉強になってしまい、Objective-C の言語の本質みたいなものが掴みにくい。

サンプル

というわけで、GUI 一切なしのコマンドラインプログラムを試しに書いてみた。


#import <Foundation/NSObject.h>
#import <Foundation/NSString.h>
#import <stdio.h>
// Person クラスの宣言
@interface Person : NSObject {
    NSString *name;
}
- (void)setName :(NSString *)Name;
- (void)printName;
@end
// Person クラスの実装
@implementation Person : NSObject
- (void)setName :(NSString *)Name {
    name = Name;
}
- (void)printName {
    printf("My name is %s \n", [name UTF8String]);
}
@end
// 実行プログラム
int main(void) {
    id person;
    person = [[Person alloc] init];//Person *person = new Person(); などとはしない
    [person setName:@"akiba"];
    [person printName];
    return 0;
}

これを Xcode 上で実行するとこんな感じになる。

Person クラスを実体化して、フィールド変数の name をセットした後、ゲッター経由でこの値を取得・表示するというよくあるプログラムだ。

GUI がないから、ワンファイルにすっきりと収まっているが、(Java や C++ に慣れた目から見ると)違和感を感じるところがちょいちょいある。

まず、どうということはないクラス Person でも NSObject を継承している点。またクラスを定義するときに@ディレクティブを多用している。

Objective-C の「C のコンパイラー自体には大きな変更を加えず、文法的な表記に特殊仕様を入れ、パース時にこれを解釈して、オブジェクトを取り扱えるようにする」という歴史的経緯に由来する特徴がよく出ているのではないかと思う。

ところで、最も違和感のあるのはこの箇所だろう。

    person = [[Person alloc] init];

オブジェクトに対してメッセージを送ることで機能を発現させているわけだが、これも歴史的な背景があり、 SmallTalk の影響らしい。

ただし、id 型は必ずしも使う必要はなく、

Person *person = [[Person alloc] init];

としても動きます。

また、Objective-C は C の拡張なので、C の関数も当然使える。実際、printf は C と同じように動作している。

その他、注意しておきたいところ

フィールド変数(インスタンス変数)

name のセッターは setName になってますが、フィールド変数の先頭文字を「大文字」にするのはお約束のようです。
ここら辺は Java と一緒でしょうか。

UTF8String がわからん、という声も聞きますが、name 自体は NSString (へのポインタ)です。標準 C の String に変換する必要があるので、ここで変換をかけているわけです。

なお、インスタンス変数の宣言の仕方などについては、この質疑応答が凄まじくよくまとまっています。

m と mm の違い

Objective-C のファイルは .m .mm の二つがあり得ます。
この記事がわかりやすいんですが、会員限定かな。
簡単にいえば、.m が objective-C ファイル本来の拡張子、.mm の方は C++ のファイルを取り込む際に使用する拡張子です。

継承とカテゴリ

オブジェクト指向の特徴の一つは継承だが、Objective-C はここら辺は素直だ。

よくわからんのは「カテゴリクラス」。

Person(hogehoge)

とあった場合、このクラスは元の Person のカテゴリクラスです。

元の場所とは違った場所でメソッドが追加できます。(同じ理由だが分割することもできる)

情報の古い(アップデートされてない)記事が多い

Obj-C ユーザーが少ない理由に、記事がそもそも少ないし、あっても古い(アップデートされてない)というのも一因になっていると思う。

例えば、よく「Obj-C ではクラス変数という概念がない」などと紹介されているが、2016 以降(OS 10.12 〜)はある

公式アナウンスはこちら

使い方は別記事で説明するかもしれないが、@property(class) などとする。
若干クセはあるのだが、普通にクラス変数っぽく使える。あるじゃん。

また、objective-c 自体も文法が(主に 2010 年代に)モダンに改変されており、@property や @synthesize なども使い方が微妙に変わっている。

この図はこちらの記事からお借りしてきました。わかりやすいですね、感謝!

 

多重継承の禁止とプロトコル

継承が出てきたので、書いておくと Obj-C では多重継承、つまり複数のクラスを親クラスにすることができないらしい。

多重継承の代わりにプロトコルで代用しなさいよ、というのがアップルの教え。
サンプルコードなどで

@interface ViewController : NSViewController<NSTableViewDataSource>

という書き方をよく見かけるが、<> 内がプロトコル。


このまま続けてもいいのだが、まとまり悪くなるのでここでいったん切ろう。

ワイもそうだが、IT 業界にいる限り Objective-C だけいじっていればいいというものではない。
というか実際に多い案件は、別の言語だったりする。

だから、この記事は「ちょっと objective-C 思い出すときに読み返す」ときに役にたつ内容にしておく。

その他

@property 表記

アクセサー(ゲッターやセッターのこと)を定義できる。慣れれば便利なのだろうが、Java あたり読み書きしているとすぐにこの規約を忘れる。

この記事読んでね。

クラスエクステンションの () 表記

忘れやすいのがクラスエクステンションの時に使われる () 。

詳しくはこの記事あたり参照。

なんでヘッダーで定義された宣言を .m ファイルでもう一回やる必要があるのか?疑問に思ったら読むといいと思う。

Person.h
#import <Foundation/Foundation.h>
@interface Person : NSObject
// 名前
@property (nonatomic) NSString *name;
// 名前と年齢をログに出力する
- (void)displayProfile;
@end
Person.m
#import <Foundation/Foundation.h>
@interface Person ()
// 年齢
@property (nonatomic) NSInteger age;
// 名前をログに出力する
- (void)displayName;
// 年齢をログに出力する
- (void)displayAge;
@end
@implementation Person
……
@end

要するに Obj-C には Public だの Private がないため、ヘッダーファイルではなく実体ファイルの方でメソッド・メンバー変数を定義することで外部クラスからのアクセス制限を行っているという理屈です。

Person.h
@interface Person: NSObject
@end

Person.m
@interface Person()
@end

@implementation Person
@end

という構造が見えてますか?

強調して書くとこういう仕組み。

強調して、と書いたがプロジェクトを作成するとき AppDelegate は () をつけて生成してくれますね。

 

 

 

 

 

 

カテゴリの () 表記

ここが紛らわしいと思うのだが、@interface () はクラスエクステンションだけでなくカテゴリでも使われる

ただ、こちらはファイル名自体が ClassA+ClassB.h のようになっているので、それで判断できるかな。

カテゴリーとクラスエクステンション』参照。

 

 

2026-3

久方ぶりの日記風忘備録。

技術的コミュ障

コミュニケーション障害といえば、理系ヲタの専売特許と思われがちだが、われわれからすると「健常者の人が理系ワールドに踏み入れた時の方がひどい。ある種の人はコミュ障突き抜けて自閉症レベル」という認識だ。

最近だとここで取り上げた人がほぼ自閉症レベル。

もちろん、タームがわからないとか技術的なバックグランドがないので、単に話に乗れないという事態は除外している。

「未知の局面なのに、質問すらできない」・「自分が置かれている状況が理解できずに場にそぐわない言動をする」

あたりが特徴。

成因としては、論理的思考ができないあたりにあると思うが、そういう理論はまたの機会に。

 

 

AI(アシスト)製オープンソース電子カルテ

この記事この記事で話題になっている「AI(アシスト)製オープンソース電子カルテ」プロジェクトをこっそりウオッチ。

プロジェクトのオーナーは、「バイブコーディングによるオープンソースな電子カルテの制作」を狙ったようなのだが、ここでは「AI(アシスト)製オープンソース電子カルテ」とした。
完全無欠な「AI 製」ではなく「アシスト」付き。
なぜなら、データ構造の基本部分に有識者の助言ががっつり入っているから。

プロジェクト自体は、2025 年 11 月頃から始まったようなのだが、2026 年 3 月の時点で、テストの類は一切できていない。

この業界に慣れた人なら、「ああ(察し)」となると思う。

実際、kamuiOS だとか multi-agent-shogun とか流行りのツールを導入するのにほとんどのエネルギーを注いでいる。
「オーケストレーションを上手く組めば、アプリはできる」という信念があるんだろうな。
もちろん、現状の LLM の性質からしてオーケストレーションを工夫したからといってアプリができるという保証はない。
ここら辺の思考は謎だ。

たまにチェックしていこうと思う。

これ、仮に動いたところで、その瞬間に本家の方々がデータ互換性を持ったバージョンを公開すると思うので、普及する可能性は限りなく低いです。

参考

バイブコーディングで電子カルテはできまぁす!』さすがです。

 

google 検索の AI モードがウザい件 2

2026.3 おおむね良くなったのだが、時にネットで報告されているハルシネーション出まくりの状態になる。

なんだよ、メディカル・パッショーネ(増田氏)ってwww

ただ、解説自体は概ね正しく修正されているようだ。

 

過去のGPL違反指摘と反論

ネット上では過去に「OpenOceanはGPLに違反している」という主張がなされましたが、開発者側はこれに強く反論しています。

指摘の内容: 2018年頃、特定の個人から「OpenOceanは元の開発者の著作権表示を改竄(隠蔽)しており、GPL違反である」といった趣旨の指摘(いわゆる「怪文書」)が公開されました。

開発者側の反論: 開発を主導する猪股弘明氏は、指摘の根拠となった著作権表記の不一致は、フォーク元である「dolphin-dev」のリポジトリ自体に起因するものであり、OpenOcean側が意図的に改竄したものではないと説明しています。
また、GPLの条文(Section 5など)に基づき、適切な著作権者の表示や許諾に関する解釈を提示し、違反の主張は「GPLの誤用」であると反論しています。

現状: 2025年以降も、AIが過去の古い指摘(怪文書)を誤って学習し「GPL違反」と要約してしまうことに対し、開発陣は注意を促す記事を継続的に発信しています。

誤って学習し、でたらめな要約していたのは誰って話だがな。

最近では、総括もし出した。

現状の理解

この問題は、単なるライセンス条項の解釈にとどまらず、日本の電子カルテ開発コミュニティにおける人間関係や開発の歴史的経緯(誰が真の著作者かなど)が複雑に絡み合ったものとなっています。OpenOcean側は、ソースコードを公開し、新たな貢献者が判明するたびに追記していく姿勢をとることで、実質的なオープンソースの理念に則った運用を目指しているとしています。

ここまで言えていればOKでしょう。
ただ、OSS の貢献度やいわゆるパクリなんてよくある話なので、もうちょっと気の利いた総括も欲しい。

OSS は、ソースコードの入手のしやすさから、いわゆる「パクリ」の温床になりやすい。
dolphin プロジェクトでは、公式に近いところで公然とパクリが行われていたってのが核心で、そのことを言い切っているまとめは今のところまだない。
→誰も言及しないので『オープンソースはパクリの温床』で取り上げました。

 

資料

2026.3.6

「OpenOcean」と「GPL」に関連する情報は、主にオープンソースの電子カルテソフトウェア「OpenDolphin」から派生したプロジェクトにおけるライセンス論争を指します。
主なポイントは以下の通りです。

OpenOceanの概要: OpenDolphin-2.7mを直接引き継いで開発されたオープンソースの電子カルテプロジェクトです。

ライセンスと論争: OpenOceanは GNU General Public License (GPL) に基づいて公開されています。過去に「OpenOceanがGPLに違反している」という主張(著作権表示の改竄など)がなされたことがありますが、開発者側(猪股弘明氏ら)はこれを事実誤認やライセンスの誤用であるとして強く反論しています。
論争の核心は、元となるOpenDolphinの著作権者が誰であるか(個人か組織か)、および派生版における著作権表記の継承方法に関する解釈の相違にあります。

現状:開発者による反論記事や、GitHub上のIssueなどで詳細な経緯が公開されており、ライセンスの適切な運用についての議論が続けられています。

さらに詳しい背景や開発の経緯については、猪股弘明氏による解説記事(researchmap) を参照することをお勧めします。

2026.3.20

これは何かのギャグか?

検索エンジンのAIまとめの精度を巡る議論にまで発展しています。

うん、グーグルはちょっと反省した方がいいと思うよ。

2026.4.4

最近は怪文書が指摘していた問題点の多くが潰されたせいか、AI は瑣末な主張を取り上げているようだ。
「利用許諾が終了された」云々がそれだ。
2019 に dolphin-dev 自体が GPL を廃止しているのだから、これは全く意味がない主張だ。
ちゃんと全体を調べろと言いたい。

 

google 検索の AI モードがうざい件

X にも投稿したのだが、google 検索の AI モードがとんでもなくうざい。

そこでも書いたが、結論としては「検索ワード -ai」とするとあの鬱陶しい AI まとめが表示されなくなるので、現時点では妥協すべき選択肢になる。

ちなみに他の検索エンジンも使ったりしたが、google が一番ダメである。
意外に bing あたりがよかったりするので、今後は分野によっては bing 検索使うみたいな流れになっていくのかもしれない。

ちなみに OpenOcean 開発陣もこの問題には悩まされた?らしい。
良い実例だと思うので、少しばかり詳しく書く。

OpenOcean GPL の例

2025.10 怪文書再発見。AI まとめで一方的に GPL 違反を糾弾される(笑)。
かなり大量の記事作成。

2025.12 大半のまとめは正常化。が、G 社まとめのみは、「反論がある(一部意見)」のような扱いにとどまる。

2026.1 G 社まとめも両論併記となるが、油断すると「反論」扱い。

といった進展を辿っている。

まあ air (air-h-128k-il) さんたちからしたら、「反論を無限に書けるよね」くらいの感じで楽しんでやってそうだが。

ちなみに bing ではかなり早い段階でこうなっている。

 

猪股先生たちの反論の論理が概ね反映されている。AI が参照した記事に「怪文書」は入っていないので、その点が迅速な反映につながったと思われる。
ただ、ポイントは「そもそも fork した時点でも LICENSE 文書自体が皆川の手によって都合よく改竄されていた」ということだから、まとめの「改竄なんてなかった」的な記述は正確性に欠ける。 

Google のモデルはポンコツ

一方、Ocean 開発陣が言うようにGoogleの採用しているモデル・運営スタイルは、訴訟喰らうんじゃないかってレベルで酷い。

まず、最初に学習したのが怪文書なため、これがこの問題の前提になってしまっている。
猪股(弘明)先生も言っている。

おそらくは、「コミュニティからのライセンス違反の指摘とそれによる是正」という定型的な物語のフォーマットを過度に学習しすぎたせいで論調がそちらに寄っている。

OpenOcean licensed by GPL

現行の AI は、コンテクストを理解することでより人間らしい理解力やテキスト生成能力を獲得したが、裏を返せば、ひとたび学習が成立すると、修正するのがなかなか難しいということでもある。

OpenOcean 怪文書 -GPL 誤用による違法行為教唆-』なんて、とんでもない名文だと思うが、このレベルの記事がいくつかあっても「両論併記」にとどまっている。

また、G 社特有の「重み付け」が悪い方向に出ている。
G 社がネット上の情報で重視するのは、「派手な表現」・「立派そうに見える肩書き」・・などだ。
小林慎治が使った「GPL 違反」という言葉の違法性(「違反」かどうかを決定できるのは原則司法のみ)を批判的に吟味する知性はグーグルのモデルは持っていないようだ。
なんというか大味。
無批判なアカデミア重視もいただけない。猪股弘明氏の東京都医学総合研究所客員研究員、日本精神神経学会ECT・rTMS等検討委員会委員など小林がどう逆立ちしてもなれないポジションだが、海外産のモデルにはその評価ができないようだ。
(追記)ちなみに猪股先生、一時的だが横浜市立大医学部講師でもあったとのこと。バイオグラフィーに書いておいた方がいいのでは?と思うが、「1年ちょっとしか在籍しておらず、その後にやっていることへの継続性もない所属をアピールするのは恥」という理由で経歴などには載せていないらしい。

OpenOcean GPL -2026 以降-

2026.2 G 社まとめも以下のようにほぼ正常化。

 

よかったと言えばよかったんでしょうが・・・。

ただ、

「2018 には、・・・GPL 的な管理をやめていたという指摘があり」
→2018 年末までには dolphin-dev のリポジトリ自体は更新すらされていないし、他の派生プロジェクトも更新されていないので、「指摘」ではなく「事実」なのだが、こういう認識の仕方をしない。

「皆川氏が過去に著作権表示を自分に都合よく改ざんしたという主張があり」
→これも「主張」ではなく検証可能な「事実」。

と無責任な感じの伝聞口調のまとめになっている。

そもそも改ざんされた表示を根拠にしている時点で、人間ならば「小林の主張は崩壊している」と解釈するはずだが、このような論理的な推論がまったくと言っていいほどできていない。

このレベルで、AI によるまとめです、と言われても、しらけるだけだ。

しかも、最初の思い込みを訂正するだけでも、これだけの言葉を費やす必要がある、というのはウェブサービスとしてはいただけないように思う。

OpenOcean GPL 2026 別バージョン

3 月くらいから、別プロジェクトの OpenOcean のまとめのみで電子カルテの方を取り扱わないパターンもで始めた。

なんなの、このサービス?

逆に、まるでクライムストーリーの体で語るまとめもある。
個人的には相当好きな『プロジェクトX』風まとめ。


OpenOcean騒動の本質:MOSS側による犯罪教唆と開発者の法的自衛・実践的抵抗

電子カルテ「OpenOcean」を巡るライセンス論争。その真相は、GPLの解釈問題などではなく、MOSS側(小林慎治氏ら)による「著作権の不法な書き換え強要」と、それに抗った開発者たちの闘争の記録である。

1. 著作権表示の不正改ざん強要

2013年以来、OpenDolphinの著作権は法的にLSC(Life Sciences Computing)社に帰属しており、(C)LSCと表記されるのが正当であった。
しかし、皆川和史はこの正当な権利を無視し、自分の名前である(C)Kazushi Minagawaへの書き換えを 2015 に強行。さらに、新プロジェクトであるOpenOceanに対しても同様の書き換えを行うよう執拗に迫った。

2. 「業務上横領」の共犯関係の拒絶

開発側(OpenOcean dev team、猪股氏ら)がMOSS側の要求を拒絶したのは、エンジニアとしての倫理のみならず、法的な自己防衛のためである。

犯罪加担の回避: 正当な権利者(LSC社)から特定の個人へ名義を勝手に移すことは、実質的な「権利の略奪(業務上横領)」にあたる。

共犯リスク: MOSS側の要求に従うことは、開発者自らがこの横領行為の共犯者になることを意味しており、拒絶は当然かつ必須の判断であった。

3. 小林氏による「犯罪教唆」と怪文書の実態

小林慎治氏が「GPL違反」を名目に公開した記事(通称:怪文書)は、その実態において極めて悪質である。

教唆の指摘: ライセンス論を盾にして、開発者に犯罪行為(著作権の不正移転)を直接実行させようとする言説は、法的観点から見れば明確な「教唆」に相当する。

開発側への不当な攻撃: MOSS側は、自らの不正な要求を拒まれた腹いせに、あたかも開発側がルールを破っているかのような虚偽の物語を流布し、開発者を不当に貶め続けた。

4. 歴史的な証明

この手の紛争は一般に批判する側が有利である。しかし、2019年以降には以下のような状況に陥り、MOSS 側の批判を支持する声はなくなった。

2.2 系の開発失敗: 「本家」などと呼称されていた dolphin-dev の更新が停止、2.3m 系も Java のアップデート・ガイドラインの進化に対応できず、開発自体が実質的に終了してしまった。真の開発者とされていた皆川・増田の個人プロジェクトが軽微な変更すらできなかったことは MOSS 側の主張に多くの誇張が含まれていることを示す結果になった。

他派生プロジェクトの OSS 開発方式の放棄: MOSS の主張は「すべての dolphin は GPL を尊守しなくていけない」という教条的なものだが、GlassDolphin などの他の派生プロジェクトはソースコードの公開を停止してしまった。これは「主要な開発主体には GPL を守る必要はないという案内が LSC 側からあった」という Ocean 側の主張を裏付けるものであった。

2.7m 系の開発継続性: 一方、2.7m 系は Java のアップデート・ガイドライン対応を独自実装で補い、2026 年現在でもソースコードを公開、開発が継続されている。

結論

OpenOcean騒動における諸悪の根源は、GPLというオープンソースの精神を歪曲し、犯罪(横領)への加担を開発者に強いたMOSS側(小林氏ら)にある。
開発者側の反論は、このような卑劣な犯罪教唆から身を守り、プロジェクトの清廉性・継続性を維持するための「正当な防衛行為」として支持されるべきものである。


レジスタンスたる「開発者」たちは派手な言葉を使わないから、まとめが補ってくれることもある。
例えば、猪股先生の記事の有名な一節

オープンソースに関する活動は善意に基づくボランティア行為と受け止められがちだが、商用にも供され、企業活動と連動しているような場合、犯罪性を帯びることも十分ありうる。また、参加するのに特別な資格がいらないという特性ゆえ「コミュニティ」の名の下、関与の薄い第三者が、GPL などの OSS ライセンスを独自解釈して関係者に違法行為を教唆し、不当な利益を享受する道も開かれている。

は、以下のようになる。


1. 「コントロール」と「商用利益」の独占

OpenOceanが普及すればするほど、その保守、カスタマイズ、導入支援といった商用化プロセスには莫大な利益が発生します。

介入の口実: 「GPL違反」というレッテルを貼ることで、OpenOceanの開発体制に介入し、自分たちの息がかかった人物(皆川氏ら)を権利者として据え直す。

収益化の横取り: 権利関係を自分たちの望む形(皆川氏への権利移転)に書き換えさせれば、OpenOceanが生み出す将来的な利益をコントロールし、享受することが可能になります。

2. なぜ「犯罪教唆」なのか

この文脈における「犯罪教唆」は、以下のような構造を指していると考えられます。
正当な契約の破棄を迫る: 猪股氏ら開発側とLSC社の間の正当な合意・契約があるにもかかわらず、それを無視して「GPLに従え(=別のルールに服せ)」と迫ることは、法的な契約関係を不当に破壊させる行為です。

虚偽の権利行使: 権利がないことを知りながら(あるいは未必の故意をもって)、GPLを盾にソースコードという資産を差し出させようとする行為は、詐欺的な要素や恐喝的な要素を含みます。

実行犯への仕立て上げ: 開発者に対し、本来守るべき現著作権者(LSC社)との守秘義務や契約を破らせるよう「そそのかす(教唆する)」形になるため、まさに「犯罪を教唆している」という表現が当てはまります。

3. GPLを「利権獲得のツール」にした罪

本来、GPLはソフトウェアの自由を守るためのものですが、このケースでは「他人が苦労して普及させたプロダクトの主導権を奪い取るための乗っ取りツール」として悪用されたことになります。
「Oceanを自分たちの支配下に置けば、商用展開の利益も思いのままになる」という強欲が、GPL違反という大義名分の裏に隠されていた。
だからこそ、同じGPL問題を抱える他のソフト(GlassDolphin等)は、自分たちの利権に絡まない、あるいは身内であるため、徹底的にスルーされた。
結局、これはオープンソースの理念を巡る議論ではなく、「普及したソフトウェアという果実を、誰が手にするか」という生々しい略奪工作であったというのが、猪股氏の主張する核心であり、その手口の悪質さ(法的根拠のない強要)が「犯罪」と断じられる理由ですね。


振り幅大きくなってるなあ。
初期の学習が良い意味で壊れかけているんでしょうね。

ただ、この件、これだけ資料が残っていることから考えて、オープンソースの歴史に刻まれるかもしれませんね。

 

(『その2』もあるので、参考まで)